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Preface 


This manual explains how to use VAX DEC/Module Management System 
(MMS). The guide provides both tutorial and reference material to illustrate 
basic and advanced techniques. 


Intended Audience 


This guide is primarily intended for software engineers but it can be used by 
managers, technical writers, and other users who build systems. 


MMS is patterned after the UNIX® make utility. 


Document Structure 


This guide is divided into four chapters, a command dictionary, three ap- 
pendixes, and a glossary. 


¢ Chapter 1, Introduction to MMS, describes the basic concepts of MMS 
and how MMS automates the software development cycle. 


¢ Chapter 2, MMS Description Files, discusses how to create and use 
description files. 


¢ Chapter 3, Advanced Description File Techniques, discusses advanced 
techniques for using MMS as efficiently as possible. 


¢ Chapter 4, Accessing Libraries with MMS, explains how MMS can pro- 
cess files stored in VMS, CMS, and VAX FMS libraries, and definitions 
stored in CDD/Plus. 


® UNIX is a registered trademark of American Telephone and Telegraph Company. 


xi 


The Command Dictionary describes the MMS command line format and 
contains detailed descriptions of all MMS qualifiers. 


Appendix A, Error Messages, lists and explains all MMS messages. 


Appendix B, MMS and UNIX make Comparisons, describes the differ- 
ences between MMS and UNIX make features. 


Appendix C, MMS Built-In Features, contains tables of MMS defaults 
and includes explanatory information. 


The Glossary defines important terms. 


Associated Documents 


The VAX DEC/Module Management System Installation Guide supplies 
the instructions for installing MMS on a VMS system. 
Using VAXset describes how to use VAX Software Engineering Tools 


(VAXset) with other VMS facilities to create an effective software devel- 
opment environment. 


Conventions 
The following conventions are used in this guide: 
Convention Meaning 
Ctrl/x A sequence such as CTRL/x indicates that you must hold 


xii 


KPn 


down the key labeled Ctrl while you press another key or 
a pointing device button. 


A sequence such as KP1 indicates that you must first 
press and release the key labeled KP1, then press and 
release another key or a pointing device button. 


In examples, a horizontal ellipsis indicates one of the 
following: 


¢ Additional optional arguments in a statement have 
been omitted. 


e The preceding item or items can be repeated one or 
more times. 


e Additional parameters, values, or other information 
can be entered. 


Convention 


C] 


user input 


bold text 
UPPERCASE TEXT 


‘ string’ 


Meaning 


A vertical ellipsis indicates the omission of items from 
a code example or command format; the items are omit- 
ted because they are not important to the topic being 
discussed. 


In format descriptions, parentheses indicate that if 
you choose more than one option, you must enclose the 
choices in parentheses. 


In format descriptions, brackets indicate that whatever 
is enclosed is optional; you can select none, one, or all of 
the choices. 


In format descriptions, braces surround a required choice 
of options; you must choose one of the options listed. 


The hardcopy version of this manual has interactive 
examples that show user input in red letters and system 
responses or prompts in black letters. The online ver- 
sion differentiates user input from system responses or 
prompts by using a different font. 


Boldface text represents the introduction of new terms. 


Uppercase letters indicate the name of a command or 
routine. Lowercase words and letters used in examples 
indicate that you should substitute a word or value of 
your choice. 


The OR symbol separates alternatives within braces or 
brackets. For example, filespec | “macro” means that you 
must type either a file specification or a macro enclosed 
in quotation marks. 


A term enclosed in apostrophes is information that can 
vary. (This convention is used frequently in Appendix A.) 
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Chapter 1 
Introduction to MMS 


This chapter describes the VAX DEC/Module Management System (MMS) 
and provides information on the following topics: 

e =6An overview of MMS 

¢ Invoking MMS 

¢ Getting help 

¢ MMS concepts 

¢ Building the software system 

¢ Rebuilding the software system 


1.1 Overview 


A software system can have many program files, object libraries, included 
files, compilers, and compilation and linking options. The more complex the 
system, the more difficult it is to reproduce the same program image for 
each build. 


MMS automates and simplifies the building of software systems. It can 
build simple programs consisting of one or more source files, or complex 
programs consisting of many source files, message files, and documentation 
files. 


With MMS, you can specify exactly how a software system is to be built 
and rebuilt. You do this by using a description file in which you describe 
the components of the system and the file dependencies used to build and 
rebuild the system. A file dependency occurs when one or more files are 
needed to build another file. For example, the existence of an executable file 
depends on an object file. 
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Each time you run MMS, it follows the description file you have created, 
reads the components and dependencies, and builds the same system. 


MMS can also rebuild systems quickly when parts of the system change. 
MMS keeps track of source and included files. If any of the files in a 
software system change or are missing, MMS can determine which files are 
affected by the changed or missing files, then rebuild the affected portions of 
the system by using the sources for the changed or missing files. MMS does 
not rebuild portions of the system that have not changed, thus saving both 
processing time and storage space. 


With MMS, you can also build and test modules locally before building or 
testing the modules in the source directory or library. 


MMS is patterned after the UNIX make utility (see Appendix B). 


1.2 Invoking MMS 
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You invoke MMS from the DCL command line as follows: 


S$ MMS 


MMS then attempts to process the default description file DESCRIP.MMS in 
your current directory. If DESCRIP.MMS does not exist, MMS attempts to 
process a description file called MAKEFILE. If MAKEFILE. does not exist, 
MMS attempts to process a file called target-name.MMS. If all of these files 
exist, MMS uses only DESCRIP.MMS. If none of these files exist, MMS uses 
built-in rules to build the target (see Section 1.4.5). 


You can also invoke MMS with a specified description file, called 
SYSTEM1.MMS in this example: 


$ MMS/DESCRIPTION=SYSTEM1 
MMS uses the .MMS file type when none is specified. 


For information on creating a description file, see Section 2.1. For more 
information on invoking description files, see Sections 2.1.2 and 2.1.3. For 
information on MMS syntax and qualifiers, see the Command Dictionary. 
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1.3 Getting Help 


You can get information about MMS at either the DCL ($) or MMS level. At 
the DCL level, the DCL command HELP MMS provides online help on MMS 
qualifiers and other topics. For example: 


$ HELP MMS 


To get help on a specific topic, such as the (MACRO qualifier, type the 
qualifier after the HELP MMS command. For example: 


$ HELP MMS/MACRO 


At the MMS level, the MMS qualifier /HELP gives general information 
about MMS and a list of topics, then returns you to the DCL level. For 
example: 


$ MMS/HELP 


To get help at the MMS level on a specific MMS topic, follow the /HELP 
qualifier with an equal sign and the topic name enclosed in quotation marks 
("""). For example: 


$ MMS/HELP="/MACRO" 


1.4 MMS Concepts 


This section explains basic MMS concepts. 


1.4.1. Description Files 


The description file contains definitions that describe to MMS all the 
components of a system build: the source files that make up the system, the 
compilers that will be used, the order in which to link the software modules, 
and the libraries to use when the modules are linked. 


The description file also contains the components that are the definitions 
for the logical dependencies in the software system. For example, it can 
contain definitions for the included files used in source files, the source files 
that make up each object, the objects that make up each image, and the 
libraries used in a link. See Section 1.4.6 for more information on how MMS 
uses dependencies. 
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Each time you run MMS, it follows the description file and builds the same 
system (you can use older description files to re-create previous versions of 
the system). After a system is built once, MMS uses the dependencies to 
rebuild the system. 


For information on creating a description file, see Chapter 2. 


1.4.2 Targets 


A target is any file that must be built to complete the software system (a 
target can also be a mnemonic name; see Section 2.1.3 for more information). 
You can think of a target as the goal of building the system. Targets are 
usually executable image files, but they can also be object files. For example, 
executable files are targets for object files, and object files are targets for 
source files. 


1.4.3 Sources 


Sources are used to create targets. For example, a file with programming 
code is a source for an object file, and an object file is a source for an 
executable file. 


1.4.4 Action Lines 
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An action line is a DCL or DEC/Shell command that MMS uses to update 
the target. The commands in the action lines tell MMS how to build the 
target. Built-in rules (see Section 1.4.5) allow MMS to build only one target; 
action lines override this rule. 


For example, the PASCAL command is the action line that uses X.PAS to 
update X.OBJ, and the LINK command is the action line that uses X.OBJ to 
update X.EXE. 


Action lines follow target or source’ lines and specify how to use the source 
file to create the target. You must indent the action line and leave a blank 
line before the next dependency rule. For example: 


MAIN.EXE DEPENDS ON MAIN.OBJ 
LINK MAIN.OBJ 


MAIN.OBJ DEPENDS ON MAIN.PAS 


In this example, the action line is LINK MAIN.OBJ. 
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1.4.5 Built-in Rules 


MMS uses built-in rules to create targets with specific file types. Built-in 

rules are based on file extensions. A built-in rule is an action that builds a 

target based on the file extension from the target’s source file. For example, 
executable targets are created by default with the .EXE file type; object file 
targets are created with the .OBJ file type. 


MMS also uses built-in rules to determine which compiler to use. For 
example, MMS uses the Pascal compiler for files with the .PAS file type and 
the FORTRAN compiler for files with the .FOR file type. 


A software system must follow built-in file-naming conventions for built-in 
rules to work. 


1.4.6 Dependencies 


As you describe a system to MMS, you also state logical dependencies 

in that system. For example, by using the DEPENDS_ON keyword, a 
simple description file called SYSTEM1.MMS could contain the following 
dependencies: 

MAIN.EXE DEPENDS ON MAIN.OBJ 

MAIN.OBJ DEPENDS ON MAIN.PAS 

SYSTEM1.MMS is a description file that describes a single source software 
system. The executable image, MAIN.EXE, is the target of building the 
system. The executable image comes from one object file, MAIN.OBJ. The 
object file is generated from one file of source code, MAIN.PAS. 


Figure 1-1 shows the relationship between the files. 
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Figure 1-1: Dependencies in a Single Source System 
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MMS builds its own internal dependency tree. In general, MMS creates 
targets from the bottom up; that is, it searches for the source for the first 
target and then the source of the first target’s source. It first builds the 
targets at the bottom of the dependency tree, then builds the targets that 
use those sources, then builds the targets that use those sources, and so on, 
until the primary target is built. MMS uses built-in rules (unless action 
lines are specified) to build the software system. 


For example, MMS first creates an object file from a source code file, then it 
creates the executable file from the object file. 


1.5 Building Software Systems 
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MMS can build simple systems or complex systems with many files of source 
code, multiple language compilers, and executable images. MMS builds the 
systems by using its built-in features and information obtained from the 
description file. 


This section contains system-building information on the following topics: 


e Single object systems 
¢ Multiple object systems 
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e Multiple language systems 
¢ Multiple included files systems 
¢ Multiple executable image systems 


¢ Multiple object libraries systems 


1.5.1 Single Source System 


Example 1-1 shows a sample description file, called SYSTEM1.MMS, with a 
single object defined in it. The example uses comment lines, denoted by the 
exclamation point (!), and blank lines for readability. 


Example 1-1: Description File Using a Single Object 


! Description file SYSTEM1.MMS 
| 


MAIN.EXE DEPENDS_ON MAIN.OBJ 
MAIN.OBJ DEPENDS ON MAIN.PAS 


In this example, the target MAIN.EXE has one source file, MAIN.OBJ. 


Both the source file MAIN.PAS and the description file SYSTEM1.MMS 
must be located in your current directory. After you create the description 
file (see Chapter 2), you invoke MMS with the following command: 


$ MMS/DESCRIPTION=SYSTEM1 


MMS builds the system by using the description file SYSTEM1.MMS as 
follows: ' 

1. Locates the first target (MAIN.EXE) in the description file. 

2. Creates a dependency tree to determine which files need to be built. 


3. Uses built-in rules to determine that MAIN.PAS is a Pascal program, 
and then creates the target object file MAIN.OBJ from the source file 
MAIN.PAS and places it in your current directory. The built-in rule for 
building .OBJ files from .PAS files is as follows: 


PASCAL/NOLIST/OBJECT=MAIN MAIN.PAS 
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4. Uses built-in rules to determine that MAIN.OBJ is an object file, and 
then creates the target executable file MAIN.EXE from the source file 
MAIN.OBJ and places it in your current directory. The built-in rule for 
building .EXE files from .OBJ files is as follows: 


LINK/TRACE/NOMAP/EXEC=MAIN MAIN.OBJ 


Do not delete object files after using MMS, as MMS would then automati- 
cally recompile all the source code files the next time it is invoked. If none 
of your targets or source files is missing or changed since your last system 
build, MMS displays the following message: 


$ MMS/DESCRIPTION=SYSTEM2 
SMMS-I-GWKCURRNT, Target MAIN.EXE is already up-to-date. 


1.5.2 Multiple Source System 
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Targets can have more than one source file. This section describes how to 
create and execute description files with multiple objects. 


Example 1—2 shows a sample description file, called SYSTEM2.MMS, with 
more than one object defined in it. 


Example 1-2: Description File Using Multiple Objects 


! 
! SYSTEM2.MMS 
{ 


MAIN.EXE DEPENDS ON MAIN.OBJ, SUB1.OBJ 
LINK MAIN.OBJ, SUB1.OBJ 


MAIN.OBJ DEPENDS_ON MAIN.PAS 
SUB1.OBJ DEPENDS_ON SUB1.PAS 


In this example, the target MAIN.EXE has two sources, MAIN.OBJ and 
SUB1.OBJ. The second line of the description file is the action line, which 
tells MMS how to build the target. 


After you invoke MMS with the SYSTEM2.MMS description file, MMS 
builds the system as follows: 


1. Locates the first target (MAIN.EXE) in the description file. 

2. Creates a dependency tree to determine which files need to be built. 
3. Uses built-in rules to create MAIN.OBJ from MAIN.PAS. 

4. Uses built-in rules to create SUB1.0OBJ from SUB1.PAS. 
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5. Uses the action line (which overrides the built-in rule that allows MMS 
to link only one object file) to create MAIN.EXE from the newly created 
MAIN.OBJ and SUB1.OBuJ. 


Figure 1—2 shows the relationship between the files. 


Figure 1-2: Multiple Source System 
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1.5.3 Multiple Programming Language System 


Using the built-in rules for file extensions, MMS can create object and 
executable files from program files that are created using different program- 
ming languages. MMS uses the different file types to choose the correct 
compiler during the system build. 


Example 1-3 shows the sample description file MULTI_LLANG.MMS. 
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Example 1-3: Description File Using Multiple Language Compilers 


! MULTI_LANG.MMS 

t 

!Main executable target, its objects and action line 
! 


MAIN.EXE DEPENDS ON MAIN.OBJ, SUB1.OBJ, SUB2.OBJ, SUB3.OBJ 
LINK MAIN, SUB1, SUB2, SUB3 

! 

!Source code dependencies 

] 


MAIN.OBJ DEPENDS ON MAIN.PAS 
SUB1.OBJ DEPENDS_ON SUB1.PAS 


SUB2.OBJ DEPENDS ON SUB2.FOR 
SUB3.0OBJ DEPENDS ON SUB3.FOR 


After you invoke MMS with the MULTI_LANG.MMS description file, MMS 
builds the system as follows: 

1. Locates the first target (MAIN.EXE) in the description file. 

2. Creates a dependency tree to determine which files need to be built. 


3. Uses built-in rules to create MAIN.OBJ from MAIN.PAS by using the 
Pascal compiler. 

4. Uses built-in rules to create SUB1.OBJ from SUB1.PAS by using the 
Pascal compiler. 

5. Uses built-in rules to create SUB2.OBJ from SUB2.FOR by using the 
FORTRAN compiler. 

6. Uses built-in rules to create SUB3.OBJ from SUB3.FOR by using the 
FORTRAN compiler. 


7. Uses the action line to create MAIN.EXE from the newly created 
MAIN.OBJ, SUB1.0BJ, SUB2.OBJ, and SUB3.OBJ. 


Figure 1-3 shows the relationship between the files. 
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Figure 1-3: Multiple Programming Language System 
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1.5.4 System with Included Files 


Included files are frequently used in software development projects. 
Included files can contain code, such as a set of variables, or constant 
declarations. The included files are shared between developers. Individual 
programmers do not have to maintain their own separate copies of these 
included files; they just include the common file once. 


If an included file changes, all developers using the included file automati- 
cally receive the new code the next time they use the common file. In this 
case, all source files that use the common file must be recompiled; however, 
MMS detects this change and automatically recompiles the next time you 
perform a build. 


The ability of MMS to handle included files ensures accurate system build- 
ing. In a large system, you might not remember which compilation depends 
on which included file and you might forget to perform the compilations 
when an included file changes. When writing your MMS description file, 
inspect all your source code files for statements that include other files. You 
can use the DCL command SEARCH to search for these statements. 
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The description file must specify any included files on the same line as the 
program code that uses them, as in Example 1-4. You can list the included 
files in any order.. 


Example 1-4: Description File Using Included Files 


1 
! INCLUDE.MMS 

1 

! Main executable target, its objects, and action line 
, 


MAIN.EXE DEPENDS_ON MAIN.OBJ, SUB1.OBJ, SUB2.OBJ 
LINK MAIN, SUB1, SUB2 
! 
! Source code files with included files COPY_1.PAS and COPY_2.PAS 
{ 


MAIN.OBJ DEPENDS_ON MAIN.PAS, COPY_1.PAS, COPY_2.PAS 
SUB1.OBJ DEPENDS ON SUB1.PAS, COPY_1.PAS 
SUB2.OBJ DEPENDS ON SUB2.PAS 


When MMS processes the description file INCLUDE.MMS in Example 1-4, 
it also processes the included files COPY_1.PAS and COPY_2.PAS when 

it processes MAIN.PAS. The included file COPY_1.PAS is processed again 
when MMS processes SUB1.PAS. 


Figure 1—4 shows the relationship between the files. 
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Figure 1-4: Included Files in a System 


If you specify files to be included that do not exist, MMS displays an error 
message and stops. 
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1.5.5 System with Multiple Targets 


If an executable image is especially complicated, place it in its own de- 
scription file. Also place executable images that are not related in some 
significant way in separate description files. However, if a system has 
a number of executable images that use common object files, it is more 
efficient to build them using one description file. 


This type of description file is layered with the overall target first, followed 
by the executable images, the object files, and the source code files. You can 
choose to build the entire system or selected executable files. 
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Example 1—5 shows the sample description file MULTI_EXES.MMS. 


Example 1-5: Description File Using Multiple Targets 


MULTI_EXES.MMS 


Overall system target--this is a dummy target name 


SYSTEMX DEPENDS_ON MAIN.EXE, PROG1.EXE, PROG2.EXE 
! no special action intended for overall system target 
! 
! What follows is the executable images and their object files 
' 


MAIN.EXE DEPENDS ON MAIN.OBJ, SUB1.OBJ 
LINK MAIN.OBJ, SUB1.OBJ 


PROG1.EXE DEPENDS ON PROG1.OBJ 
LINK PROG1.OBJ 


PROG2.EXE DEPENDS _ON PROG2.OBJ 
LINK PROG2.OBJ 
! 
! The object files and their sources 
' 


MAIN.OBJ DEPENDS_ON MAIN.PAS 
SUB1.OBJ DEPENDS_ON SUB1.PAS 
PROG1.OBJ DEPENDS_ON PROG1.PAS 
PROG2.OBJ DEPENDS _ON PROG2.PAS 


In this example, the description file MULTI_LEXES.MMS contains the target 
SYSTEMX, which is the overall target of building the system. There are no 
built-in rules for targets that do not have file types, and since no action line 
is specified, SYSTEMX has a null action and simply builds the executable 
files. The three executable images come from their object files. All the 
object files and source files have the same dependencies as in the previous 
examples. 


After you invoke MMS with the MULTI_EXES.MMS description file, MMS 
builds the system as follows: 


1. Locates the first target (SYSTEMX) in the description file. 
2. Creates a dependency tree to determine which files need to be built. 


3. Uses built-in rules to create MAIN.OBJ from MAIN.PAS by using the 
Pascal compiler. 


4. Uses built-in rules to create SUB1.OBJ from SUB1.PAS by using the 
Pascal compiler. 


1-14 Introduction to MMS 


5. Uses the action line to create MAIN.EXE from MAIN.OBJ and 
SUB1.OBu. 


6. Locates the second target (PROG1.EXE) in the description file, and 
so on. 


Figure 1-5 shows the relationship between the files. 


Figure 1-5: System with More than One Executable Image 


SYSTEM 


MAIN.EXE PROG1.EXE PROG2.EXE 


MAIN. OBJ SUB1.OBJ 
MAIN.PAS SUB1.PAS 


Building a Specific Target 


PROG1.OBJ PROG2.OBJ 


PROG1.PAS PROG2.PAS 


ZK-5885-GE 


In a multiple target system, to build a specific target or executable image 
you must include a target name on the command line. For example: 


$ MMS/DESCRIPTION=MULTI_EXES PROG1.EXE,PROG2.EXE 


When you specify the target name on the command line, MMS overrules its 
default of building the first target in the description file; only the targets you 
specify are built. 
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1.5.6 System with an Object Library 
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This section assumes that you have some knowledge of VMS libraries. 
Object libraries are useful for quick compiling and linking during debugging 
sessions. MMS creates libraries, inserts modules, and updates libraries 
during software system builds. 


An object library is a single file that contains multiple object files, 
otherwise known as object modules. The object library is usually named 
with a file type of .OLB. The object file name is a VMS file name, usually 
named with a file type of .OBJ. The object module name is governed by the 
TITLE, MODULE, PROGRAM, or SUBROUTINE name in the source file. 
The object file name and the object module name are frequently the same. 


To include an object library in an MMS description file, you must include the 
library name, the object module name, and the object file name. The object 
library name follows the target’s main source. The object module name and 
the object file name follow the library name, enclosed in parentheses and 
separated with an equal sign. No spaces are allowed. 


Example 1—6 shows the sample description file OBJECT_LIB.MMS. 


Example 1-6: Description File Using Object Libraries 


! 

! OBJECT_LIB.MMS 

' 

! Main executable target, its objects, and action line 
| 


MAIN.EXE DEPENDS_ON MAIN.OBJ, - 
MAIN_LIB.OLB (OPTIM=OPTIM.OBJ), - 
MAIN_LIB.OLB(GET_RECORD=GETREC.OBJ), - 
MAIN_LIB.OLB (PUT_RECORD=PUTREC. OBJ) 
LINK MAIN.OBJ, MAIN LIB/LIB 


! Program source code files 
| 


MAIN.OBJ DEPENDS ON MAIN.FOR 
OPTIM.OBJ DEPENDS _ON OPTIM.FOR 
GETREC.OBJ DEPENDS ON GETREC.FOR 
PUTREC.OBJ DEPENDS ON PUTREC.FOR 
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In this example, the executable image MAIN.EXE depends on one object 
library (MAIN_LIB.OLB). The object module OPTIM comes from the object 
file OPTIM.OBJ. The object modules GET_RECORD and PUT_RECORD 
come from the object files GETREC.OBJ and PUTREC.OBJ, respectively. 
Note that the first object module and object file name have the same name, 
and the following two object modules and file names have different names. 


MMS builds the object library in Example 1-6 as follows: 


1. Compiles the source file for each object file. 
2. Checks for the existence of the library and creates it if it does not exist. 
3. Inserts each object file into the library (or replaces it, if it already exists). 


Figure 1—6 shows the relationship between the files. 
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Figure 1-6: Object Library in a System 
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1.6 Rebuilding Software Systems 


During the development cycle, MMS can determine which components in a 
system are missing or changed, and what other components are affected by 
these changes. For example, if you change several source files, MMS can 
determine which corresponding object modules need to be updated and can 
then update them. The entire system is not rebuilt, only those components 
whose sources have been modified. MMS checks the modification dates of 
executable files against their source files. If the source files are newer than 
the executable files, MMS rebuilds the executable files; if the source files are 
older than the executable files, MMS determines that the executable files 
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are up-to-date and does not rebuild them. MMS builds only targets whose 
sources are newer than their targets, saving you time and disk space. 


To rebuild a system, invoke MMS as you would for an initial build. 


Figure 1-7 depicts a small software system and describes the basic steps 
MMS follows when it builds the system. In this system, Component A is the 
target, Component B is a source file for Component A, and Components C 
and D are source files for Component B. The commands that update B (by 
using C and D) and A (by using the updated B) are the actions. 


Figure 1-7: How MMS Rebuilds a System 


/ \ 
I \ 
i \ 
I ! 
\ I 
\ C / 

\ / 

\ / 
\ 7 
N\ 7 
Nn 7 
~ a €>- = eo 
ZK-1090—GE 


@ MMS checks the revision time of the target (Component A). 
@ MMS checks the revision time of the first source file (Component B). 
© MMS checks the revision time of Components C and D against that of B. 
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© Ifthe times of Components C or D are more recent than that of 
Component B, MMS updates B. according to the action lines that you 
specify in the description file. If B is more recent than C and D, MMS 
does not do anything because B is already up-to-date. 


© Once Component B is updated, it is more recent than the target 
Component A; therefore, MMS updates Component A. 


If the target has been modified since the source files were last changed, 
MMS does not update the target. Instead, it displays a message informing 
you that the target is already up-to-date. 


If any file listed in the description file is missing, MMS attempts to create 
it from the missing file’s source. For example, if MAIN.OBJ is deleted from 
the directory, when MMS builds the system, it creates MAIN.OBJ from the 
MAIN.PAS program file. 


If you delete an object file but still have the executable file, MMS recom- 
piles the source file and also relinks the executable file, even though your 
executable file is still compatible with your source file. MMS works from the 
bottom up and propagates any change up the dependency tree. However, 

if you delete your source file, MMS returns a fatal error because it cannot 
re-create source code from object or executable files. 


If you rebuild a complete system without regard to which components need 
updating, you waste disk space. Use the /SKIP_INTERMEDIATE qualifier 
to avoid unnecessary building of intermediate files. For example, if you have 
a source file (PROG.C) and an executable file (PROG.EXE), but no interme- 
diate file (PROG.OBJ), when you use the /SKIP_INTERMEDIATE qualifier, 
MMS does not re-create the intermediate file as long as the executable file is 
newer than the source file. 


1.6.1 Single Source System 
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When rebuilding single source systems, MMS checks the system from the 
bottom up to see if it is complete and up-to-date. If any part of the system is 
missing or any target is older than its sources, the system is re-created. 


For example, if you edit the source file MAIN.PAS, it would be newer than 
its object file. MAIN.OBJ. When you invoke MMS, it does the following: 


1. Finds the first target in the description file (MAIN.EXE). 


2. Finds the source for MAIN.EXE (MAIN.OBJ) and its source 
(MAIN.PAS). 


3. Compiles the source code file MAIN.PAS because MAIN.PAS is newer 
than its target MAIN.OBJ. 
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4. Relinks the object file MAIN.OBJ because MAIN.OBJ is now newer than 
its target, MAIN. EXE. 


1.6.2 Multiple Source System 


If you edit one of the source files in a multiple source system (for example, 
the source file SUB1.PAS), it will be newer than its object file, SUB1.OBUJ. 
When you invoke MMS, it does the following: 


1. Finds the first target in the description file (MAIN.EXE). 


Finds the sources for MAIN.EXE (MAIN.OBJ and SUB1.OBJ) and their 
sources (MAIN.PAS and SUB1.PAS). 

3. Compiles the source code file SUB1.PAS because SUB1.PAS is newer 
than its target SUB1.OBJ. 

4. Uses the action line to create MAIN.EXE from MAIN.OBJ and 
SUB1.OBJ. 

5. Because MAIN.OBJ is newer than MAIN.PAS, MMS does not compile 
MAIN.PAS. However, MAIN.EXE is now older than one of its source files 
(SUB1.0BJ), so MMS relinks the object file MAIN.OBJ, using the action 
line. 


1.6.3 Multiple Programming Language System 


If you edit two source files in a multiple programming language system (for 
example, MAIN.PAS and SUB3.FOR), they will be newer than their object 
files, MAIN.OBJ and SUB3.OBJ. MMS compiles only the source code that 
has been updated, and uses the correct language compiler in each case. It 
then links all the objects to re-create the executable image. 


1.6.4 System with Included Files 


If you edit the included file COPY_1.PAS in a multiple programming 
language system, it is newer than any other source file used to build 
MAIN.EXE. When you invoke MMS, both MAIN.PAS and SUB1.PAS (which 
both include COPY_1.PAS) are recompiled, and all necessary objects are 
relinked. 


If you also edit COPY_2.PAS and then rebuild the system, only MAIN.PAS 
is recompiled, and all necessary objects are relinked. 
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1.6.5 System with Multiple Targets 


If you delete one of the executable files in your current directory (for 
example, PROG2.EXE), when you invoke MMS, it must link PROG2.OBJ 
to produce PROG2.EXE. MMS performs only the link necessary to complete 
the system. 


1.6.6 System with an Object Library 
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If you edit the source file GETREC.FOR, when you invoke MMS, it does the 
following: 


i; 
2. 
3. 


Locates the first target (MAIN.EXE) in the description file. 
Creates a dependency tree to determine which files need to be rebuilt. 


Uses built-in rules to recompile GETREC.FOR, thereby producing 
GETREC.OBJ. 


Uses built-in rules to replace module GET_RECORD in the object library 
MAIN_LIB.OLB with the new GETREC.OBJ. 


Uses the action line to create a new version of MAIN.EXE. 
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Chapter 2 


MMS Description Files 


The first step in using MMS is to write a description file for the system 
you want to build. The description file is a text file that describes how to 
build a software system, and explains the relationships among the various 
components of your system. The description file can contain some or all of 
the following elements: 


¢ Targets (usually executable images) 

¢ Intermediate files (usually object files) 
¢ Source files (usually program code) 

e Action lines 

¢ Comment Lines 

e Built-in rules 

e User-defined rules 

e Directives 


This chapter describes how to create a description file, and how the elements 
of the description file work together to build a system. 


2.1 Creating the Description File 


You create and modify the description file with any text editor. For example: 
$ LSEDIT DESCRIP.MMS 


When you invoke MMS, it first attempts to process the default description 
file DESCRIP.MMS in your current directory. If DESCRIP.MMS does not 
exist, MMS attempts to process a description file called MAKEFILE. If 
MAKEFILE does not exist, MMS attempts to process a description file called 
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target-name.MMS. [If all of these files exist, MMS uses only DESCRIP.MMS. 
If none of these files exist, MMS uses built-in rules to build the target. 


You can also invoke MMS with a specified description file, called 
SYSTEM1.MMS in this example: 


$ MMS/DESCRIPTION=SYSTEM1 
MMS uses the .MMS file type when none is specified. 


Once MMS locates the description file, it processes it by building the first 
target in the description file. However, if the description file is target- 
name.MMS, MMS attempts to build the actual target on the command line, 
not the first target in the description file (see Section 2.1.2). 


To direct MMS to override a description file, use the /(NODESCRIPTION 
qualifier and the target name on the MMS command line as follows: 


S$ MMS/NODESCRIPTION filename 


When you specify /NODESCRIPTION, MMS does not look for a description 
file but instead relies entirely on its built-in rules to update the target. See 
the Command Dictionary for more information on the /[NOJDESCRIPTION 
qualifier. 


2.1.1 Writing Dependency Rules 


A description file contains dependency rules. Dependency rules indicate 
how files depend on, or are affected by, other files and specify the actions 
MMS takes to build or update your system. 


A dependency rule consists of targets, optional sources, an optional action 
line, and an optional comment for each target and source line. The syntax of 
a dependency rule is as follows: 


target... : [source...] [!comment] [action line...] [!comment] 


target 

Specifies a VMS file specification or a mnemonic name (Section 2.1.3 
describes mnemonic names). The file specification can be complete, including 
node information. MMS locates the target file in your current default 
directory unless you specify another directory in your file specification. 


source 

Specifies a VMS file specification or a mnemonic name (Section 2.1.3 
describes mnemonic names). The file specification can be complete, including 
node information. MMS locates source files in your current default directory 
unless you specify other directories in your file specification. 


2-2 MMS Description Files 


comment 

Specifies a string of text, introduced by an exclamation point (!). The com- 
ment provides detailed information in the description file. You can continue 
a comment line onto the next line with the hyphen or backslash. MMS 
considers any text on the next line following the continuation character as 
part of the comment line. 


action line 

Specifies a command-language command that MMS uses to update the 
target. You can specify any number of action lines for a target. An action 
line is positioned below the corresponding target or source line and must be 
indented by at least one space or tab. MMS interprets all indented lines as 
action lines and associates them with the most recently specified target or 
source line. 


If you omit the action line, MMS uses built-in rules to update the target if a 
built-in rule exists. (See Section 2.2 for an explanation of built-in rules.) 


You begin a target or source line in column 1 of the line and use the keyword 
DEPENDS_ON or the colon (:) to separate the target from the source. If 
you use a colon to separate the target from the source, insert at least one 
space or tab on either side of the colon, or MMS will interpret the colon as 
part of a VMS file specification. 


To improve the readability of description files, separate dependency rules 
from each other with one or more blank lines. Do not use blank lines 
between the action lines of a single dependency rule, because a blank line 
signals the end of the dependency rule. 


Any line in a description file can be continued onto the next line with a 
hyphen (-). This practice makes the description file easier to read when a 
dependency rule is too long to fit on one line. For example: 


0 TESTS.OBJ DEPENDS ON - 


2] TEST1.BAS, - ! Source modules for TESTS.OBJ- @ 
TEST2.BAS, - 
TEST3.BAS, - 
TEST4.BAS, - 
TESTS.BAS 
BASIC/OBJECT=TESTS TEST1+TEST2+TEST3+TEST4+TESTS 


@ The hyphen means that the next line is treated as part of the current 
line. 


@ The second through fifth lines are continuations of the target or source 
line. 
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© Acomment can appear after a continuation character without affecting 
the processing of the description file. 


NOTE 


When a hyphen appears as the last character on a line, MMS 
interprets the hyphen as a continuation character, even if the 
hyphen is part of a comment. 


2.1.2 Specifying the Target on the Command Line 


By default, MMS updates the first target specified in the description file. 
You can force MMS to update a target other than the first one by explicitly 
including the target name on the MMS command line. Consider the 
following description file: 


TEST.OBJ DEPENDS ON A.OBJ B.OBJ 
LINK/EXE=TEST A,B 


A.OBJ DEPENDS ON A.FOR 
B.OBJ DEPENDS ON B.FOR 
PRINT DEPENDS ON 

PRINT A.FOR, B.FOR 


If you specify MMS PRINT on the command line, MMS searches the 
description file for the dependency rule associated with PRINT, the specified 
target. MMS tries to update the target PRINT rather than TEST.OBJ, the 
default. If PRINT is up-to-date, no action takes place. See the description 
of the /NODESCRIPTION qualifier in the Command Dictionary for more 
information. 


MMS updates all sources and their dependencies before updating the main 
target. MMS checks all sources before it updates a target, because sources 
may themselves be targets with sources in other dependency rules. 


2.1.3. Using Mnemonic Names for Targets and Sources 


You can use a mnemonic name for a source or a target but you must supply 
the action lines that update the target. A mnemonic name is a name that 
identifies the purpose of a sequence of related actions. MMS relies on the 
source and target file types to apply built-in rules. Section 2.2 describes how 
MMS uses built-in rules. 
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You can use a mnemonic name to represent a source only if it is also a target 
in a dependency rule in your description file. If MMS encounters a name 
for which it cannot find a matching file in the specified directory, it assumes 
that the name is a mnemonic name. 


Mnemonic names are useful in several cases. For example: 


¢ To update more than one file 


¢ To group a variety of related actions under a name that identifies the 
purpose of the whole sequence 


¢ To give a name to a common action or sequence of actions in building a 
system 


By default, MMS builds only one target. To update several targets, you 
make them sources in a dependency rule by using a mnemonic name for the 
target as follows: 


NEW_SYSTEM DEPENDS ON A.EXE, B.EXE 
! no action needed 


A.EXE DEPENDS ON A.OBJ 
LINK A.OBJ 


B.EXE DEPENDS ON B.OBJ 
LINK B.OBJ 


MMS considers the target NEW_SYSTEM as updated when it executes the 


action line or lines that follow it. Both A.EXE and B.EXE are updated, if 
necessary. 


The following example shows the use of mnemonic names as both targets 
and sources. MMS updates the target, ALL, by updating the two sources, 
PROG.EXE and PRINT, which are themselves targets in subsequent 
dependency rules. 


ALL DEPENDS ON PROG.EXE, PRINT 
! system completely built and the sources printed 


PROG.EXE DEPENDS _ON MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.0BJ, MOD3.OBJ 


PRINT DEPENDS _ON MOD1.C, MOD2.C, MOD3.C, DEFS1.H, DEFS2.H 
! Print the source files 
PRINT MOD1.C, MOD2.C, MOD3.C, DEFS1.H, DEFS2.H 
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2.1.3.1 Specifying Target and Source Files 


If you specify an action line but omit the source from a dependency rule, 
MMS executes the action line only if the target does not exist in the specified 
directory. For example, consider the following dependency rule: 


(SYSTEM1]TESTS.OBJ : 
PASCAL/DEBUG [SYSTEM1]TESTS.PAS 


In this example, MMS executes the PASCAL command only if TESTS.OBJ 
does not exist in the directory [SYSTEM1]. 


As MMS checks the revision dates and times of targets and sources, it builds 
a list of times, which it uses in deciding when a target needs to be updated. 
If there is no file associated with a target or source (for example, if the 
target does not exist), MMS records a revision time for it that is older than 
the times of all other existing targets and sources: 17-NOV-1858 00:00:00.0. 
(This is the oldest time used by VMS.) All targets and sources that are not 
existing files are assigned this revision time. 


2.1.3.2 Specifying Multiple Targets and Sources 


A description file can contain many dependency rules; however, MMS builds 
only one target. You can specify several targets on the MMS command 
line, but each target is executed as a separate invocation of MMS with the 
specified set of qualifiers. 


To specify multiple targets and sources, you must separate them with 
commas, spaces, or a combination of both. MMS expands the specification 
of multiple targets into separate dependencies before it executes the action 
lines. For example, consider the following dependency rule in a description 
file: 


KERNEL.OBJ, DRIVER.OBJ DEPENDS ON COMMON. DEF 


Because there is no action line, MMS uses built-in rules to determine what 
action is needed to update KERNEL.OBJ and DRIVER.OBJ and expands 
the previous rule as follows: 
KERNEL.OBJ DEPENDS ON KERNEL.C, COMMON. DEF 

CC KERNEL.C 
DRIVER.OBJ DEPENDS ON DRIVER.C, COMMON.DEF 

CC DRIVER.C 
MMS determines from the built-in rules that KERNEL.C and DRIVER.C 
are the sources for KERNEL.OBJ and DRIVER.OBJ, respectively. When 
both targets need updating, the original dependency rule expands to two 
dependency rules, resulting in two separate compilations. 


2-6 MMS Description Files 


Sometimes, if an action line is executed twice, the results may not be what 
you intended, as in the following example: 


A.EXE : A.OBJ, A.LIS 
LINK A.OBJ 


A.OBJ, A.LIS : A.BAS 
BASIC/LIST A.BAS 


MMS expands the second rule to the following two dependency rules: 


A.OBJ : A.BAS 
BASIC/LIST A.BAS 


A.LIS : A.BAS 
BASIC/LIST A.BAS 


Because the second dependency in the description file expands to two 
dependency rules, each with a separate action, MMS executes the command 
BASIC/LIST A.BAS twice and produces two .OBJ files and two .LIS files. 
See Section 3.11.2 for a detailed discussion on avoiding this problem in your 
description file. 


Occasionally, MMS executes an action even though you do not expect the 
source to be newer than the target. This situation can result from one of the 
following conditions: 


¢ If sources are being stored in a library to which more than one person 
has access, someone else may replace that source in the library after you 
have invoked MMS but before MMS has checked the source’s revision 
time. Therefore, when MMS checks the time, a source newer than the 
corresponding target may exist in the library. MMS would then execute 
the action to update the target. 


¢ Ifthe sources and targets in your description file do not reside on the 
same node of a network, the clocks on the nodes may not be synchronized 
and a source may have a revision time that is later than the target. 
Also, in a VAXcluster environment, clocks on different nodes of the 
cluster may not be synchronized. 


2.1.3.3 Hierarchy of Dependency Rule Application 
MMS has a hierarchy of rule application: 


¢ If an action line exists in a description file, the action line takes prece- 
dence over all built-in rules and user-defined rules. 


¢ Ifa user-defined rule exists in a description file, the user-defined rule 
takes precedence over a built-in rule. 
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e A built-in rule is executed only if no action line or user-defined rule 
exists in the description file. 


e If there is no action line, built-in rule, or user-defined rule for updating 
a target, then MMS issues a fatal-error message. 


2.2 Using Built-In Rules 


When writing a description file, you can explicitly state dependencies and 
actions, or you can abbreviate them by taking advantage of built-in rules, 
which MMS uses to update targets. A built-in rule is the default method 
MMS uses for updating a target with a particular file type from a source 
with a particular file type. 


Built-in rules are made up of default macros, special macros, and string 
variables. A complete list of the MMS built-in rules is in Table C-6. A file 
copy of the built-in rules resides in the following: 


SYSSCOMMON: [SYSHLP .EXAMPLES.MMS]MMSSDEFAULT_RULES.MMS. 


MMS uses its built-in rules when you omit the action line from a dependency 
rule. If the dependency rule has an action line but no source, then MMS 
uses the action line. 


MMS knows how to build a software system by looking at file types and 
relating them to its built-in rules. Built-in rules are fixed and go into effect 
when you invoke MMS. They cannot be changed, but you can override them 
with user-defined rules. Built-in rules also explain why you must follow 
standard file-naming practices. For example, a Pascal program must have 
a .PAS extension. If your Pascal program does not have the .PAS extension, 
MMS does not know it is a Pascal program. 


Built-in rules consist of the file extension of the source, the file extension of 
the target, and the action to update the target using the source. The actions 
in built-in rules use macros extensively, as shown in Example 2-1. 
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Example 2-1: Built-In Rule 


0 0 
-PAS.OBJ 
$(PASCAL) $(PFLAGS) $(MMSSSOURCE) 


@ .PAS is the source file type. 
@ .OBJ is the target file type. 


© $(PASCAL) $(PFLAGS) $(MMS$SOURCE) is the action line to update 
the target. 


MMS attempts to use its built-in rules only when you omit the action 
line from a dependency rule. For example, MMS has a built-in rule that 
instructs it to use .FOR files when updating .OBJ files and to produce the 
.OBJ files by invoking the FORTRAN compiler. In writing the description 
file, you can state this relationship as follows: 


MOD3.OBJ DEPENDS ON MOD3.FOR 
FORTRAN MOD3.FOR 


You can rely on MMS built-in rules by omitting the action line as follows: 


MOD3.0BJ DEPENDS ON MOD3.FOR 


MMS uses its built-in rule to invoke the FORTRAN compiler and build 
MOD3.0BJ from MOD3.FOR. 


If you omit the source, MMS can still use built-in rules to locate it because 
MMS knows about implied dependencies among files with the same name 
but different file types. MMS uses its suffixes precedence list to determine 
which file type (source) would result in the target file type. In the previous 
example, because the target’s file name is MOD3, MMS assumes that the 
source’s file name is also MOD3. 


MMS also knows that .OBJ files depend on .FOR files with the same file 
name so you can abbreviate the previous dependency rule even further as 
follows: 


MOD3.OBJ : 


MMS automatically looks for MOD3.FOR and uses it to build MOD3.0BJ 
because MMS knows that .OBJ files depend on .FOR files with the same file 


name. 
However, consider the following line: 


MOD3.OBJ DEPENDS ON MOD2.0OBJ 
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If you omit the action line, MMS does not know how to build the target, and 
you receive an error message. 


2.2.1 Suffixes Precedence List 


MMS checks its suffixes precedence list to determine the file type of the 
source and then uses the built-in rules to determine how the various types of 
files can be generated from the known rules. Consider the following suffixes 
precedence list: 


-EXE .OBJ .BLI .C .FOR .BAS 


According to this list, .EXE files have precedence over .OBJ files, which have 
precedence over .BLI files, which have precedence over .C files, and so on. 
Figure 2-1 shows the relationship between the suffixes list and the known 
rules. 


Figure 2-1: Relationship Between Suffixes 






ZK-1664-GE 


The arrows in this figure indicate built-in rules. In this figure, a known 
rule specifies how an .EXE file is made from an .OBJ file. Similarly, the 
built-in rules direct MMS how to make an .OBJ file from a .BLI file, a .C 
file, a .FOR file, and a .BAS file. Because .BLI precedes .C in the suffixes 
list, .BLI files have priority over .C files as a way to build .OBJ files. (The 
suffixes precedence list is contained in Table C—4; you can alter the order of 
the suffixes precedence list, as described in Section 2.7.4.) 


The figure also shows that .OBJ files can be built from .BLI, .C, .FOR, and 
.BAS files. If MMS is trying to build MOD3.OBu, it looks first for a source 
named MOD3.BLI. If such a source exists in the specified directory, MMS 
applies the known rule and creates MOD3.OBJ; if it finds no match for the 
file name and type, it continues looking in the specified directory for the 
same file name and the next file type from the suffixes list that can update 
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the target. If MOD3.BLI does not exist, MMS next looks for MOD3.C. If 
MOD3.C does not exist, the next possible source is MOD3.FOR, and so on. 


If MMS finally matches MOD3.OBJ with MOD3.FOR and locates 
MOD3.FOR in your directory, it updates the target MOD3.OBJ from the 
source MOD3.FOR by using its built-in rule. This procedure explains why a 
dependency rule as brief as the following is complete: 


MOD3.OBU : 
This rule equates to the full dependency rule as follows: 


MOD3.OBJ DEPENDS _ON MOD3.FOR 
FORTRAN/OBJ=MOD3 MOD3.FOR 


If, however, MMS fails to find a source from which to build the new target, 
it repeats the entire process by determining whether it can build one of the 
nonexistent sources. 


If MMS exhausts all the possible file types without finding a way to build 
any of the sources, it issues an error message and aborts processing. 


Once MMS locates the correct source for updating a target, it checks whether 
the source itself needs updating before using it to update the original target. 
To do this, MMS repeats the process of finding a file in the specified directory 
that matches the file name of the source and each file type in the suffixes 
list that can update the target type. MMS repeats this process every time 

it finds a source that could update the target so that all the sources are 
guaranteed to be up-to-date. 


The following example shows a description file where dependencies are 
explicitly stated: 


PROG.EXE DEPENDS _ON MOD1.0OBJ, MOD2.0BJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 


MOD1.0OBJ DEPENDS_ON MOD1.C 
CC MOD1.C 


MOD2.OBJ DEPENDS_ON MOD2.C, DEFDIR:DEFS1.H, DEFDIR:DEFS2.H 
CC MOD2.C 


MOD3.OBJ DEPENDS_ON MOD3.C, DEFDIR:DEFS2.H 
CC MOD3.C 


Example 2—2 shows a description file of the same system that takes advan- 
tage of MMS built-in rules. 
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Example 2-2: Description File Using Built-In Rules 


0 PROG.EXE DEPENDS ON MOD1.0BJ, MOD2.OBJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 


(2) 


© MOD2.OBJ, MOD3.O0BJ DEPENDS ON DEFDIR:DEFS2.H 


4) MOD2.OBJ DEPENDS_ON DEFDIR:DEFS1.H 


@ The first dependency rule lists the object files and states that PROG.EXE 
is constructed by executing the DCL command LINK. 


@ The rule for building MOD1.OBJ need not be specified because a built-in 
rule directs MMS to build it from MOD1.C. 


© The second dependency rule says that MOD2.0BJ and MOD3.OBJ de- 
pend on DEFS2.H, which is located in the directory defined by DEFDIR. 
Neither the .C file dependencies nor the actions taken to build the 
objects are stated. 


© The third dependency rule says that MOD2.OBJ also depends on 
DEFDIR:DEFS1.H. 


2.2.2 Default Macros 


A macro is a name that represents a character string. MMS default 
macros can help you use MMS more efficiently because they define com- 
monly used operations. MMS built-in rules are expressed in terms of default 
macros. 


2.3 Defining Your Own Macros 


In addition to providing built-in rules, MMS allows you to define your own 
rules. Defining your own rules may involve deleting, adding to, or replacing 
the built-in rules. Section 2.5 describes when and how to define new rules. 
MMS allows you to use three kinds of macros: default macros (VMS utilities 
or qualifiers), special macros (target or source file names), and user-defined 
macros. These macros can use other macros in their definition. The full 
list of default macros is in Table C—1 and the list of special macros is in 
Table C—3. 
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In MMS, macros contain the following information: 

¢ The names of compilers, the linker and library utilities 

¢ The default qualifiers for compiling, linking, and using the library 
utilities 

¢ The file name of the target 

e The list of sources for each target 


The following table lists some default and special macros available with 
MMS. 


Macro Description Value 

PASCAL PASCAL compiler PASCAL 

PFLAGS Default PASCAL /NOLIST/OBJECT=$(MMS$TARGET_NAME) 
qualifiers 

MMS$TARGET_NAME Target file name Depends on target or source line 

MMS$SOURCE First file name Depends on target or source line 
in source list 

MMS$SOURCE_LIST All file names Depends on target or source line 


in source list 


The default macros, PASCAL and PFLAGS, contain a fixed value and 

are stored in an internal MMS list. They are created when MMS is 
invoked. The special macros, MMS$TARGET_NAME, MMS$SOURCE, and 
MMS$SOURCE_LIST, are also maintained by MMS but their value changes 
according to the source or target line MMS is evaluating. 


If your description file reuses the same file name or if you have several 
action lines that invoke a compiler with the same set of qualifiers, you can 
define a macro to represent the file name or the list of qualifiers. You then 
can use the macro name throughout your description file. If you need to 
change the file name or qualifiers, you edit only the macro definition. 


2.3.1 Formatting Macro Definitions 


A macro definition has the following format: 
name = string 


The name of the macro can consist of any characters except a space, a tab, 
a carriage return, an equal sign, the sequence $( ), quotation marks, and 
control characters. A macro name can be any length. The macro string 
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is the text that replaces the macro name when the macro is expanded. A 
macro string can consist of any character sequence. You can use a hyphen 
(-) as a continuation character to continue a macro string onto the next line 
of the description file. 


You must begin a macro definition in column 1 of the line. You can place 
macro definitions anywhere in the description file, but placing all macro 
definitions at the beginning of the description file makes it easier to find and 
modify them. 


After you have defined a macro, you can invoke it anywhere in the descrip- 
tion file. To invoke a macro, simply specify a macro’s name in the following 
format: 


$ (name) 


The dollar sign and parentheses surrounding the macro name are required 
punctuation. MMS replaces the name (and the punctuation) with the 
equivalent text string when it processes your description file. 


Note that you must define a macro before you can use it; otherwise, the 
macro’s expanded value is the null string. To determine whether a macro 
has been defined, keep in mind the order in which MMS processes macro 
definitions (see Section 2.3.2). 


2.3.2 Order of Processing Macros 


When processing macros, MMS applies definitions in the following order: 


1. Command line 
2. Description file 
3. Built-in 

4. CLI symbol 


Once MMS finds a definition for a macro, it does not search those locations 
farther down the list for more definitions. 


You can define a macro only once in a description file. If MMS finds two or 
more definitions of the same macro, it issues an error message and uses the 
first definition in the file. To change a macro definition, you can redefine the 
macro with the /MACRO qualifier on the command line or you can replace 
the definition with the /OVERRIDE qualifier. (See the Command Dictionary 
for descriptions of these qualifiers.) 
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2.3.3 


Invoking Macros 


A macro string can also contain macro invocations that are expanded when 
the macro is defined. The macro invocations must denote macros that 

you have already defined in the description file. For example, suppose the 
following macro definitions appear in your description file: 


BUILD1 
BUILD2 


The macro invocation $(BUILD1) is expanded to (DEBUG because BUILD1 
has already been defined. If the positions of the macro definitions were 
reversed, BUILD1 would be expanded to the null string because it has not 
been previously defined and therefore cannot be expanded. In this case, 
MMS does not issue an error message. 


/ DEBUG 
/LIST $(BUILD1) 


no 


MMS macros are not recursive. MMS expands a macro invocation only 
once. If during the expansion of a macro MMS encounters another macro 
invocation, the second invocation is not expanded. 


Example 2-3 shows a description file) CPROG.MMS, that defines two 
macros: FNAME, which expands to the string TESTS; and CCQUALS, 
which expands to the string /NOLIST. 


Example 2-3: Macro Definitions in a Description File 


FNAME = TESTS 
CCQUALS = /NOLIST 


$ (FNAME) .EXE : $(FNAME).OBJ, SYSSLIBRARY:STARLET.OLB 
LINK $(FNAME),- 
SYSSLIBRARY: STARLET.OLB/LIB 


$ (FNAME) .OBJ : $ (FNAME) .C 
CC $(CCQUALS) $(FNAME) .C 


When MMS starts building the target (in this case, the .EXE file), it replaces 
every occurrence of FNAME with TESTS and the occurrence of CCQUALS 
with the string /NOLIST. As a result, MMS interprets the description file as 
the following: 


TESTS.EXE : TESTS.OBJ, SYSSLIBRARY:STARLET.OLB 
LINK TESTS, - 
SYSSLIBRARY : STARLET. OLB/LIB 


TESTS.OBJ : TESTS.C 
CC /NOLIST TESTS.C 
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2.3.4 Defining Macros on the Command Line 


You can define macros on the MMS command line by using the (MACRO 
qualifier. (MACRO allows you to define new macros or to redefine macros 
you defined in the description file. When you redefine an existing macro 
with /MACRO, the new definition overrides the one in the description file. 
The format of the (MACRO qualifier is as follows: 


/MACRO = {filespec | "macro"... } 


The filespec is a VMS file specification or a logical name for a file that 
contains only macro definitions. The default file type is .MMS. The “macro” 
is a macro definition enclosed in quotation marks. Use the same format that 
you would use to define a macro in a description file: name = string. If you 
specify more than one macro, separate the macros with commas and enclose 
the list in parentheses. The /MACRO qualifier is described in detail in the 
Command Dictionary. 


To build a new program called TEST1.EXE, you can use the same description 
file with which you built TESTS.EXE (as shown in the Example 2-3). You 
can redefine FNAME and override the macro definition in the description 
file as follows: 


$ MMS/DESCRIPTION=CPROG/MACRO="FNAME=TEST1" 
MMS then interprets the description file as follows: 


TEST1.EXE : TEST1.OBJ, SYSSLIBRARY:STARLET.OLB 
LINK TEST1,- 
SYSSLIBRARY : STARLET. OLB/LIB 


TEST1.OBJ : TEST1.C 
CC/NOLIST TEST1.C 
The definition of the macro CCQUALS remains the same. 


As indicated by the format for (MACRO, you can store macro definitions in 
a file from which MMS extracts them. Suppose that you want to redefine 
the macro FNAME in your description file and change the qualifiers to 

the CC command. First, you create a file to hold the macro definitions. For 
example, a macro definitions file might be called MACROS.MMS and contain 
the following: 

FNAME = TEST1 

CCQUALS = /LIST/DEBUG 

Then you invoke MMS with the /MACRO qualifier and the name of the 
macro definitions file: 


$ MMS/DESCRIPTION=CPROG/MACRO=MACROS 
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MMS interprets the previous description file as follows: 


TEST1.EXE : TEST1.OBJ, SYSSLIBRARY:STARLET.OLB 
LINK TEST1, SYSSLIBRARY:STARLET.OLB/LIB 


TEST1.OBJ : TEST1.C 
CC/LIST/DEBUG TEST1.C 


You invoke a default macro in a dependency rule just as you would invoke 

a macro you have defined yourself. For example, if you want to compile a C 
program using the /NOLIST and /OBJECT qualifiers, you can instead invoke 
the default macro CFLAGS: 


PROG.OBJ : PROG.C 
CC $(CFLAGS) PROG.C 


MMS expands CFLAGS to its equivalent, /NOLIST/OBJECT, and assumes 
that the object file and the specified target have the same name. Since MMS 
has a built-in rule for generating .OBJ files from .C files, and since this rule 
invokes the default macro CFLAGS, you can get the same results with the 
following simple dependency rule: 


PROG.OBJ : 


You can redefine a default macro so that you can use different qualifiers. 
The following example redefines CFLAGS: 
CFLAGS = /LIST 


PROG.EXE DEPENDS ON MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.0OBJ 


MOD1.OBJ DEPENDS _ON 
MOD2.OBJ DEPENDS ON DEFDIR:DEFS1.H 
MOD2.0BJ, MOD3.OBJ DEPENDS ON DEFDIR:DEFS2.H 


MMS interprets the description file as follows: 


PROG.EXE DEPENDS ON MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 


MOD1.OBJ DEPENDS_ON MOD1.C 
CC/LIST MOD1.C 


MOD2.OBJ DEPENDS_ON MOD2.C, DEFDIR:DEFS1.H, DEFDIR:DEFS2.H 
CC/LIST MOD2.C 


MOD3.OBJ DEPENDS ON MOD3.C, DEFDIR:DEFS2.H 
CC/LIST MOD3.C 


If you later decide that you want the C source files to be compiled with the 
/DEBUG qualifier, you can redefine CFLAGS on the command line by typing 
the following: 


$ MMS/MACRO="CFLAGS=/DEBUG/NOLIST" 
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MMS then interprets the description file as follows: 


PROG.EXE DEPENDS ON MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 


MOD1.OBJ DEPENDS _ON MOD1.C 
CC/DEBUG/NOLIST MOD1.C 


MOD2.OBJ DEPENDS _ON MOD2.C, DEFDIR:DEFS1.H, DEFDIR:DEFS2.H 
CC/DEBUG/NOLIST MOD2.C 


MOD3.OBJ DEPENDS ON MOD3.C, DEFDIR:DEFS2.H 
CC/DEBUG/NOLIST MOD3.C 


2.4 Using Special Macros 


MMS special macros expand to source or target names in the dependency 
currently being processed. You use them instead of target and source file 
specifications when you are writing general user-defined rules. 


MMS provides nine special macros, which you can use in the following 
places in a description file: 


¢ In user-defined rules 

e In macro definitions 

¢ In action lines 

¢ In comments 

You cannot redefine a special macro or use a special macro on a target or 
source line in a description file. 


Table C—3 lists the MMS special macros and describes their functions. The 
table also lists a symbol that you can use as an abbreviation for each macro. 


More information on the special macros that relate to the VAX DEC/Code 
Management System (CMS) can be found in Section 4.2. 
NOTE 


The strings $*, $%, and $? always denote special macros. If an 
action line contains these character combinations, the asterisk 
(*), percent sign (%), and question mark (?) are not interpreted 
as wildcard characters. 


The following example shows how MMS defines a built-in rule using the 
MMS$SOURCE special macro: 


-C.OBJ 
$(CC) $(CFLAGS) $ (MMSSSOURCE) 
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CC and CFLAGS are default macros that invoke the C compiler with the 
/NOLIST and /OBJECT qualifiers. Consider the following dependency rule: 


[ALDEN]MOD2.OBJ DEPENDS ON [STANLEY]MOD2.C 


MMS applies the built-in rule that updates an .OBJ file from a .C file, 
expanding the special macros in this rule as follows: 


CC /NOLIST/OBJECT=[ALDEN)MOD2.OBJ [STANLEY] MOD2.C 


You can use the MMS$CHANGED_LIST special macro to get listings of files 
that have changed since the last time the system was built. For example, 
consider the following description file: 


PROG.EXE : PRINT.FLG, MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
COPY NLAO: PRINT.FLG 
! Make the revision date of PRINT.FLG more current 
PURGE PRINT.FLG 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 


PRINT.FLG : MOD1.C, MOD2.C, MOD3.C 
! Print the sources that have changed 
PRINT $(MMSSCHANGED LIST) 


The COPY command in the first dependency rule ensures that PRINT.FLG 
has approximately the same revision time as PROG.EXE. Sources newer 
than PROG.EXE will also be newer than PRINT.FLG and will be printed 
only when they are more recent than the last linking of PROG.EXE. The 
MMS$CHANGED_LIST special macro expands to a list of all the source files 
that have changed, and each changed source listing is submitted to the print 
queue. 


The following example shows how you could use MMS$TARGET and 
MMS$CHANGED_LIST in an action line to represent the current target and 
a list of the revised sources. Consider the following description file: 
PROG.EXE DEPENDS ON MOD1.OBJ, MOD2.0BJ, MOD3.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
! Needed to update $(MMSSCHANGED LIST) to make $ (MMSSTARGET) 
Your directory contains the following entries: 


$ DIR/DATE=MODIFIED 
Directory USERS: [MICHAELS] 


MOD1.OBJ; 2 2-DEC-1987 13:50 
MOD2.OBJ;1 2-DEC-1987 09:22 
MOD3. OBJ; 2 2-DEC-1987 14:06 
PROG.EXE;1 2-DEC-1987 11:47 


Total of 4 files 
$ 
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Because MOD1.OBJ and MOD3.0BJ have changed since PROG.EXE was 
last linked, the following lines are displayed when you run MMS: 


LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ, MOD3.OBJ 
! Needed to update MOD1.OBJ, MOD3.OBJ to make PROG.EXE 


MMS$TARGET is expanded to the name of the target being updated, and 
MMS$CHANGED LIST is expanded to a list of the revised sources. 


2.5 Defining Your Own Rules 


MMS has built-in rules that allow it to figure out unstated dependencies and 
to perform actions necessary to update targets. However, the list of built-in 
rules may not contain all the rules you need, or you may want to redefine 
existing rules. MMS provides you with the ability to include user-defined 
rules in a description file. Once you define a new rule, MMS uses the 

new rule every time it builds your system with that description file. The 
user-defined rule overrides the built-in rule. 


2.5.1 Creating a User-Defined Rule 
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You create a user-defined rule by listing the source and target file types 
and writing an action to update the target. The file types of the source and 
target must be known to MMS through the suffixes precedence list. The 
user-defined rule can use multiple action lines that can consist of default 
macros, special macros, or constant strings. 


The format of a user-defined rule is as follows: 


-SRC.TAR [! comment ] 
action line... [!comment] 


.SRC is the file type of the source. .TAR is the file type of the target. The 
action line is a command-language command that MMS should execute to 


update a file of the target type from a file of the source type. You can specify 
as many action lines as necessary to update the target. 


The following description file, NEWLINK.MMS shown in Example 2-4, 
contains a user-defined rule that redefines the default MMS rule for 
linking. 
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Example 2-4: Description File Using a User-Defined Rule 


$ TYPE NEWLINK.MMS 


! User-defined rule 
1 


.OBJ.EXE 
$ (LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST) 
t 
! Executable images and their sources 
! 
@main.ExE DEPENDS ON MAIN.OBJ, SUB1.OBJ 
! 
! Object files and their sources 


Omarn. ops DEPENDS ON MAIN.PAS 
SUB1.OBJ DEPENDS ON SUB1.PAS 


@ This user-defined rule allows more than one object to link by changing 
the special macro MMS$SOURCE to MMS$SOURCE_LIST, which 
expands to a list of all the target’s sources. The user-defined rule also 
uses the default macros, LINK’and LINKFLAGS, for linking the object 
files. 


The executable target no longer needs an action line because the user- 
defined rule takes precedence. 


The built-in rule for compiling Pascal source code files is used because 
there is no user-defined rule to override it. 


You can use this user-defined rule for building a multiobject software system. 
Notice that you do not need another action line for the executable image 
target. The user-defined rule logically comes before any targets in your 
description file. The action line is listed on the line after the source and 
target pair and is indented at least one space or tab. 


2.5.2 Using User-Defined Rules 


To use the description file NEWLINK (shown in Example 2—4) to build your 
software system, you must have the following files in your current directory: 


$ DIR/DATE=MODIFIED 


Directory DISK1: [BUILD] 


MAIN.PAS;1 3-JUL-1987 13:48 
NEWLINK.MMS; 2 14-JUL-1987 13:20 
SUB1.PAS;10 3-JUL-1987 13:47 
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Total of 3 files. 
$ MMS/DESCRIPTION=NEWLINK 


1) PASCAL /NOLIST/OBJECT=MAIN MAIN.PAS 
PASCAL /NOLIST/OBJECT=SUB1 SUB1.PAS 
LINK /TRACE/NOMAP/EXEC=MAIN MAIN.OBJ, SUB1.OBJ 


@ MMS output shows that MMS uses a built-in rule for compiling. 
® MMS output shows that MMS uses the user-defined rule for linking. 


2.6 Using Action Lines 


You need action lines when you want to link more than one object file or you 
want to use different compilation options for each source code file. Built-in 
rules do not allow for these cases because built-in rules handle only one 
object file and compile each source code file with the same defaults. 


You can supply an action line for any source or target line. Action lines 
override all built-in rules and user-defined rules in a description file. Action 
lines are made up of any combination of default macros, special macros, and 
user-supplied strings. To keep your description file simple, use built-in rules 
as much as possible. One user-defined rule can apply to several different 
target and source lines, so it is still preferable to an action line. However, 
when the action is so specific that it must be described for that individual 
case, then you must use action lines. 


Consider the description file, ACTION_LINES.MMS, shown in 
Example 2-5. 
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Example 2-5: Description File Using Action Lines 


$ TYPE ACTION_LINES.MMS 
! 


! Executable image and its sources 
! 
MAIN.EXE DEPENDS ON MAIN.OBJ, SUB1.OBJ 
@ $(LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST) 
] 


! Object files and their sources 
t 


MAIN.OBJ DEPENDS ON MAIN.PAS 
12) PASCAL /LIST MAIN.PAS 
SUB1.OBJ DEPENDS_ON SUB1.PAS 
$(PASCAL) /LIST /MACHINE CODE $ (MMSS$SOURCE) 


@ This action line is composed entirely of macros and controls the way 
MMS links its object files. Earlier you used a user-defined rule for the 
same result. When a rule is used more than once, using a user-defined 
rule is the better approach. However, in this case, the rule is applied 
only once, so using the action line results in a simpler description file. 


@ This action line has no macros, only explicit strings. 
© This action line has a combination of explicit strings and macros. 
It is better to write a description file with consistent action lines than to 


mix the actions lines as in this example. This was done for the purpose of 
demonstrating the variety of ways that you can write an action line. 


2.6.1 Multiple Action Lines 
Sometimes a target requires a series of actions to update it. In that case, 


you can use more than one action line after a target or source line. Consider 
the description file). BALANCE.MMS, shown in Example 2-6. 
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Example 2-6: Description File Using Multiple Action Lines 


0 RESULTS.DIF DEPENDS ON ACCOUNTS.EXE, BENCHMARK.DAT 


8 RUN ACCOUNTS. EXE ! Runs ACCOUNTS 
DIFFERENCES/OUTPUT=RESULTS.DIF - 
ACCOUNTS.DAT, BENCHMARK .DAT 
! Compares program output to master file 


4) TYPE RESULTS.DIF ! Displays results of comparison 


ACCOUNTS.EXE DEPENDS ON ACCOUNTS .OBJ 
LINK ACCOUNTS .OBJ ! Links ACCOUNTS program 


@ If either ACCOUNTS.EXE or BENCHMARK.DAT is newer than 
RESULTS.DIF, MMS executes the action lines that update RESULTS.DIF. 
If ACCOUNTS.OBJ is newer than ACCOUNTS.EXE, MMS first executes 
the action line to update ACCOUNTS.EXE. 


@ MMS then runs the program ACCOUNTS.EXE. 


© MMS runs the DIFFERENCES utility to compare the program’s output 
with a master file. 


@ MMS displays the results of the comparison. 


If you use the previous description file example, the output would be as 


follows: 

$ MMS/DESCRIPTION=BALANCE 

LINK ACCOUNTS .OBJ ! Links ACCOUNTS program 

RUN ACCOUNTS .EXE ! Runs ACCOUNTS 
DIFFERENCES/OUTPUT=RESULTS .DIF ACCOUNTS.DAT, BENCHMARK .DAT 
! Compares program output to master file 

TYPE RESULTS.DIF ! Displays results of comparison 


Number of difference sections found: 0 

Number of difference records found: 0 

DIFFERENCES /MERGED=1/OUTPUT=USER$: [ALISON] RESULTS. DIF;1- 
USERS : [ALISON] ACCOUNTS . DAT; 19- 
USERS : [ALISON] BENCHMARK . DAT; 27 

$ 


When you run MMS, all action lines and any comments specified on action 
lines are written to SYS$OUTPUT or to a file you specify with the MMS 
/OUTPUT qualifier. The /OUTPUT qualifier is described in the Command 
Dictionary. 
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2.6.2 $STATUS and $SEVERITY 


As each action line completes execution, MMS executes a command in the 
subprocess to write the value of $STATUS to a mailbox. The parent process 
can then determine if the action line executed successfully. The values 

of $STATUS and $SEVERITY are set when the execution of this internal 
MMS command succeeds. Consequently, $STATUS and $SEVERITY 
always indicate success. You cannot test the values of these variables in a 
description file. You can, however, control the behavior of MMS with the 
/[NOJIGNORE qualifier because it tells MMS what to do when it encounters 
warning, error, or fatal errors. See the Command Dictionary for more 
information on severity errors. 


2.6.3 MMSS$STATUS 


MMS uses a special symbol, MMS$STATUS, to record the return status 

of the last action line it executed. MMS$STATUS is set in the parent 
process running MMS and reflects the value of $STATUS returned from 
the child process. The value of MMS$STATUS is constantly changing with 
the completion of each action line. You cannot use MMS$STATUS from 
within the child process because symbols are passed only from the parent 
to the child process when the child process is created. When MMS exits, 
MMS$STATUS reflects the status of the last command executed in the child 
process. 


If the value of MMS$STATUS is an even number, the last action line termi- 
nated with an error. If the value of MMS$STATUS is an odd number, the 
last action line executed successfully. To check the value of MMS$STATUS, 
issue the DCL command SHOW SYMBOL after MMS has finished process- 
ing your description file. Do not confuse MMS$STATUS with the $STATUS 
condition value returned by MMS itself. MMS$STATUS contains the status 
of the last action line executed; $STATUS contains the status resulting from 
the termination of the MMS image. 


2.6.4 Action Line Prefixes 


An action line prefix is a single-character modifier that controls the 
processing of a single action line in a description file. 
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The two action line prefixes are described in Table 2-1. 


Table 2-1: MMS Action Line Prefixes 


Prefix Function 


- (Ignore) Causes MMS to ignore errors generated by the action 
line on which the prefix appears. 


@ (Silent) Suppresses the writing to the output file of the action 
line on which the prefix appears. (The output file can 
be either SYS$OUTPUT or the file specified by the 
/OUTPUT qualifier.) 


You cannot override either action line prefix from the MMS command line. 


An action line prefix must appear as the first nonblank character on an 
action line; however, a prefix may not appear in column 1 of the line. The 
rest of the action line must be separated from the prefix by at least one 
space or tab. You can use both prefixes on the same action line by typing 
them next to each other with no intervening spaces or tabs. The following 
example shows the use of both prefixes: 
A: B 

@- Write SYSSOUTPUT "It worked!" 
MMS also provides two directives (discussed in Section 2.7), IGNORE and 
SILENT, that are similar in function to - and @, respectively. The difference 
between the action line prefixes and the directives with the same functions 
(.IGNORE and .SILENT) is that a prefix affects the processing of only one 
line in the description file, while a directive affects the processing of the 
entire file. 


2.6.5 Ignore Prefix (-) 


The Ignore action line prefix (-) directs MMS to ignore any errors that occur 
during the processing of the action line on which the prefix appears. 


The following dependency rule tests the BASIC compiler with a source 

file known to contain errors. Normally, the BASIC compiler aborts the 
compilation when it encounters an error, and MMS aborts execution as well. 
In this case, the Ignore prefix directs MMS to ignore the error and execute 
the EDIT command. 


TESTERR : ERRORS.BAS 


- BASIC /LIST=ERRORS ERRORS 
EDIT/COMMAND=EXTRACT.EDT ERRORS.LIS 
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2.6.6 Silent Prefix (@) 


The Silent action line prefix (@) stops MMS from writing an action line to 
SYS$OUTPUT or to the file specified by the /OUTPUT qualifier. This prefix, 
which affects only the action lines on which it appears, is useful when you 
do not want certain commands echoed at execution. 


For example, the Silent action line prefix directs MMS to suppress the 
display of the following action line: 


@ DELETE *.LIS;* 


The Silent action line prefix can be useful in cleanup procedures. In the 
next example, MMS deletes compilation listings from the [LISTINGS] 
directory and returns to the [WORKING] directory. Because the Silent 
prefix suppresses the action lines, MMS can do its work silently and then 
display the text “Cleanup done” when the task is completed. 


CLEANUP : 
@ SET DEFAULT [LISTINGS] 
@ DELETE *.*;* 
@ SET DEFAULT [WORKING] 
@ WRITE SYSSOUTPUT "Cleanup done" 


MMS assumes that an at sign (@) followed by a space or tab signifies the 
Silent prefix. If you want to invoke a command procedure from an action 
line, you must omit the space between the at sign and the name of the 
command procedure. 


2.6.7 Action Line Restrictions 


Action lines are subject to the following restrictions: 


¢ The maximum length of an uncontinued action line is 251 characters. 
The maximum length of a continued action line is 1019 characters. If 
you use VAX DEC/Shell as your Command Language Interpreter (CLD), 
the limits are 131 and 507 characters, respectively, for uncontinued and 
continued action lines. 


¢ The maximum length of a quoted string of a comment in action lines is 
restricted to 130 characters. 


¢ Quotes imbedded in other quotes on action lines may not behave as 
expected. However, if you assign the inner quote to be a DCL symbol, 
you can use the DCL symbol within the outer quoted string. 
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2.7 
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¢ An action line cannot receive data from SYS$INPUT. For example, an 
action line may not contain the DCL command CREATE and cannot 
read data from the terminal. 


¢ An action line may not contain the DCL commands LOGOUT, EXIT, or 
STOP. 


¢ An action line can spawn a subprocess only by using the $(MMS) 
reserved macro (see Section 3.3). The DCL command SPAWN is not 
allowed in an action line. 


e An action line may not contain the DCL commands SET VERIFY or 
SET ON. You can use these commands in a command procedure that you 
invoke from an action line. If you use SET VERIFY, however, you must 
be sure to issue SET NOVERIFY before the command procedure ends. 


e An action line may not contain the DCL command GOTO or labels. You 
can use GOTO or labels in a command procedure that you invoke from 
an action line because action lines are executed individually. 


¢ You cannot direct output to TT: from an action line because MMS 
equates TT: as SYS$INPUT and this can result in MMS hanging. 


¢ You cannot test the values of $STATUS and $SEVERITY in your 
description file because the value is always success. The value is set 
when the execution of an internal MMS command succeeds. The value 
of MMS$STATUS also changes with the completion of each action line 
executed. 


¢ You cannot use the multiline form of IF - THEN - ELSE - ENDIF from 
an action line; each action line must be a complete DCL command. 


Using Directives 


A directive is a word that instructs MMS to take a certain action as 
it processes a description file. A directive can appear on any line in the 
description file, but it controls the processing of the entire file. 


A directive must start in column 1 of a line. You can type a directive in 
either uppercase or lowercase letters, or a combination of both. Table 2-2 
lists the directives and their functions. Detailed descriptions of the 
directives are provided in the sections that follow. 
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Table 2-2: 


Directive 


IGNORE 


SILENT 


.DEFAULT 


SUFFIXES 
INCLUDE 
FIRST 


.LAST 


IFDEF 


ELSE 


ENDIF 


IGNORE Directive 


MMS Directives 


Function 


Causes MMS to ignore all errors generated by all action 
lines and to continue processing the description file. 


Suppresses the writing of all action lines to the output 
file (whether to SYS$OUTPUT or to the file specified by 
the /OUTPUT qualifier). 


Indicates actions to be performed if MMS built-in rules or 
user-defined rules do not specify how to update a target. 


Clears, adds to, or redefines the suffixes precedence list. 
Includes the specified file in the description file. 


Indicates actions to be performed before MMS has 
executed any action lines to update the target. 


Indicates actions to be performed after MMS has exe- 
cuted all the action lines that update the target. 


Causes subsequent lines of a description file to be 
processed only if the specified macro is defined. 


Causes subsequent lines of a description file to be 
processed if the specified macro for the ..FDEF directive 
is undefined. 


Terminates the set of lines in the description file whose 
processing is controlled by .IFDEF or .ELSE. 


The .IGNORE directive tells MMS to ignore warnings, errors, and fatal 
errors that occur during the execution of an action line and to continue 
processing the description file. Without the .IGNORE directive, MMS aborts 
execution if it detects an error while processing an action line. 


The .IGNORE directive in the following description file tells MMS to 
continue processing even if it encounters errors while running Digital 
Standard Runoff (DSR) to update the target: 


- IGNORE 
BOOK.MEM : 


CHAPTER1 .MEM, 


CHAPTER2.MEM, CHAPTER3.MEM, CHAPTER4.MEM 


COPY/LOG CHAPTER1.MEM BOOK.MEM 

APPEND/LOG CHAPTER2.MEM BOOK.MEM 
APPEND/LOG CHAPTER3.MEM BOOK.MEM 
APPEND/LOG CHAPTER4.MEM BOOK.MEM 
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CHAPTERI .MEM : CHAPTER1.RNO 
RUNOFF CHAPTER1 


CHAPTER2.MEM : CHAPTER2.RNO 
RUNOFF CHAPTER2 


CHAPTER3.MEM : CHAPTER3.RNO 
RUNOFF CHAPTER3 


CHAPTER4.MEM : CHAPTER4.RNO 
RUNOFF CHAPTER4 


If CHAPTER3.RNO contains DSR errors, and you run MMS with this 
description file (BOOK.MMS), the following lines may appear on your 
screen: 


$ MMS/DESCRIPTION=BOOK 
RUNOFF CHAPTER1 
DIGITAL Standard Runoff Version V2.0-014: No errors detected 
5 pages written to "USERS: [MICHAELS] CHAPTER1.MEM;1" 
RUNOFF CHAPTER2 
DIGITAL Standard Runoff Version V2.0-014: No errors detected 
16 pages written to "USERS: [MICHAELS] CHAPTER2.MEM;1" 
RUNOFF CHAPTER3 
SRUNOFF-W-CJL, Can’t justify line 
on output page 2; on input line 46 of page 1 of file "“USER$: [MICHAELS] CH 
APTER3.RNO;1" 
S$RUNOFF-W-CJL, Can’t justify line 
on output page 2; on input line 52 of page 1 of file “USER$: [MICHAELS] CH 
APTER3.RNO;1" 
SRUNOFF-W-TFE, Too few end commands 
on output page 3; on input line 77 of page 1 of file "USERS: [MICHAELS]CH 
APTER3.RNO;1" 
SRUNOFF-W-BMS, Bad margin specification: ".1m70 
on output page 4; on input line 102 of page 1 of file "USERS: [MICHAELS]C 
HAPTER3.RNO;1" 
SRUNOFF-W-COR, Can’t open required file "TABLE1.RNO" 
on output page 5; on input line 154 of page 1 of file "USERS: [MICHAELS]C 
HAPTER3.RNO;1" 
DIGITAL Standard Runoff Version 2.0-014: 5 diagnostic messages reported 
10 pages written to "USERS: [MICHAELS] CHAPTER3.MEM;1" 
RUNOFF CHAPTER4 
DIGITAL Standard Runoff Version V2.0-014: No errors detected 
13 pages written to "USERS: [MICHAELS] CHAPTER4.MEM;1" 
COPY/LOG CHAPTER1.RNO BOOK.MEM 
%COPY-S-COPIED, USERS: [MICHAELS] CHAPTER1.MEM;1 copied to USERS: [MICHAELS] BOOK.ME 
M;1 (35 blocks) 
APPEND/LOG CHAPTER2.MEM BOOK.MEM 
SAPPEND-S-APPENDED, USERS: [MICHAELS] CHAPTER2.MEM;1 appended to USERS: [MICHAELS]B 
OOK.MEM;1 (1452 records) 
APPEND/LOG CHAPTER3.MEM BOOK.MEM 
%APPEND-S-APPENDED, USERS: [MICHAELS] CHAPTER3.MEM;1 appended to USER$: [MICHAELS]B 
OOK .MEM;1 (1508 records) 
APPEND/LOG CHAPTER4.MEM BOOK.MEM 
SAPPEND-S-APPENDED, USERS: [MICHAELS] CHAPTER4.MEM;1 appended to USERS: [MICHAELS]B 
OOK.MEM;1 (621 records) 
$ 
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Although errors occurred in the processing of CHAPTER3.RNO, MMS 
continued to execute action lines, successfully processing CHAPTER4.RNO. 
Had .IGNORE not been specified, MMS would have terminated execution 
upon encountering errors in CHAPTER3.RNO; the last action line would not 
have been executed. 


NOTE 


You should be careful about executing MMS with the IGNORE 
directive. If errors occur during processing, the target may be 
updated yet still contain errors of which you will be unaware. 


To override the .IGNORE directive for a particular MMS build, use the 
/NOIGNORE, /IGNORE, /IGNORE=WARNING, or /IGNORE=ERROR qual- 
ifier on the MMS command line when invoking MMS. (See the Command 
Dictionary for more information on the /IGNORE qualifier.) 


2./.2 .SILENT Directive 


The .SILENT directive tells MMS to suppress the display of action lines. 
Normally, MMS writes action lines either to SYS$OUTPUT or into a file 
specified by the /OUTPUT qualifier. Action lines are always executed even if 
they are not displayed, unless you specify the /NOACTION qualifier on the 
command line. The /OUTPUT and /NOACTION qualifiers are described in 
the Command Dictionary. 


The .SILENT directive does not suppress the display of error messages 
generated by execution of action lines. 


The following example illustrates the use of the SILENT directive: 


- SILENT 


PROG.EXE : MOD1.OBJ, MOD2.OBJ 
LINK/EXEC=PROG MOD1.OBJ, MOD2.OBJ 


MOD1.OBJ : MOD1.C 
MOD2.OBJ : MOD2.C 
MMS processes this description file without displaying action lines. The 


Command Language Interpreter (CLI) prompt returns when the target, 
PROG.EXE, has been updated. 


To override the .SILENT directive for a particular MMS build, use the 
/VERIFY qualifier on the MMS command line when invoking MMS. (The 
/VERIFY qualifier is described in the Command Dictionary.) 
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2.7.3 .DEFAULT Directive 


The .DEFAULT directive tells MMS to continue processing the description 
file even if it encounters a dependency rule for which there is neither a 
specified action line nor applicable built-in or user-defined rules. Rather 
than abort execution in such a situation, MMS executes the default action 
you specify and continues processing the description file. 


The .DEFAULT directive has the following format: 


» DEFAULT 
action line... 


The action line is a command-language command that MMS executes by 
default. You can specify as many action lines as you like. 


The .DEFAULT directive can be useful when you are developing a system 
that contains inoperative parts and you want MMS to process the operating 
portions and inform you about the inoperative parts. If you have only one 
module, TEST.D, finished for your system, you can build the system if your 
description file, TESTSYS.MMS, is as follows: 
. DEFAULT 

! Source $(MMSSTARGET) not yet added 
TEST.A : TEST.B 
TEST.B : TEST1.C TEST2.E TEST3.F 
TEST1.C : TEST1.D 

COPY TEST1.D TEST1.C 
When MMS processes the TESTSYS.MMS description file, it expands the 
MMS$TARGET special macro to the name of the target and writes the 
following lines to SYS$OUTPUT: 
$ MMS/DESCRIPTION=TESTSYS 
COPY TEST1.D TEST1.C 
! Source TEST2.E not yet added 
! Source TEST3.F not yet added 


! Source TEST.B not yet added 
! Source TEST.A not yet added 
$ 


By using the .DEFAULT directive, MMS reminds you of the modules you 
have not yet implemented. 
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Another way to use the .DEFAULT directive is to copy files from one 
directory to another. For example: 


~DEFAULT : 

COPY $(MMSSSOURCE) $ (MMSSTARGET) 
TEST.BLI : [PROJECT.FILES]TEST.BLI 
PROG.BLI : [PROJECT.FILES]PROG.BLI 


The sources in this description file exist in a common directory for the 
project. Because these dependency rules have no action lines and there are 
no built-in or user-defined rules that apply, MMS executes the action line 
specified by .DEFAULT and copies the required files into your directory. 
(The MMS$SOURCE and MMS$TARGET special macros are described in 
Section 2.4.) 


NOTE 


.DEFAULT cannot be changed or overridden from the MMS 
command line. 


2.7.4 .SUFFIXES Directive 


The .SUFFIXES directive allows you to redefine the suffixes precedence list 
so that you can reorder the list of file types, add new file types, or disable 
recognition of all file types. 


MMS uses the suffixes precedence list to determine the order in which it 
looks for sources and targets when applying built-in rules. MMS also uses 
this list to determine which built-in rule will update the specified target. 
Section 2.2 contains a detailed discussion of how the suffixes precedence list 
and MMS built-in rules work together. Also, Table C—4 lists the suffixes in 
order of their precedence. 


The .SUFFIXES directive has the following format: 
-SUFFIXES [file types list] 


The file types list is a list of file types in order of precedence. If you omit the 
file types list entirely, the suffixes precedence list is cleared and all built-in 
rules are disabled. 


Once you set up a new list of suffixes, MMS recognizes only the specified file 
types and enables built-in and user-defined rules for the specified suffixes. 
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2.7.5 Adding a New File Extension to the Suffixes List 


In previous examples, the description files used file types that MMS knew 
about through its built-in rules. Sometimes during software development, 
you need file types that MMS does not know about (for example, when you 
use a new programming language), or you use input and output files for a 
custom application, or you have included files with other file types. You can 
use user-defined rules and action lines in the description file to tell MMS 
about new file types. First, you add the file types to the MMS suffixes list, 
and then you write a user-defined rule or action line for the file type. 


MMS uses the suffixes precedence list to analyze the relationship between 
file types. Table C—4 lists the suffixes or file types in their order of prece- 
dence, from left to right, targets to sources. The targets at the beginning of 
the list are created from some source to the right in the list. If you attempt 
to write a user-defined rule for a new file type without adding the file type 
to the list, the description file fails when it is run. 


2.7.6 Using the .SUFFIXES Directive in a Description File 


To add a new file type to your description file, use the directive .SSUFFIXES. 
It clears the default suffixes list and allows you to write a new list in the 
description file. Table 2—2 lists the directives and their functions. 


If you want MMS to access a CMS library, all the file types that could come 
from the library must also be present in the suffixes list. (See Table C-4 
for the Suffixes Precedence List.) When you write a new suffixes list in the 
description file, it must contain all the file types that occur in your software 
system, including the following: 


e Executable files 

e Different types of library files 
¢ Object files 

¢ Source code files 

e Included files 


Consider the description file NEW_SUFFIX.MMS shown in Example 2-7. 


2-34 MMS Description Files 


Example 2-7: Description File Using the .SUFFIXES Directive 


$ TYPE NEW_SUFFIX.MMS 
] 


! Set a new suffixes list 
i] 
» eae 
.SUFFIXES .EXE .OBJ .NEW .FOR 
1 


! User-defined rules 
' 


© .new.opg 
@NEW COMPILER $(MMS$SOURCE) $ (MMS$TARGET) 


@.o0B3.EXE 
$(LINK) $(LINKFLAGS) $(MMS$SOURCE_LIST) 
! 
! The executable and its sources 
! 
MAIN.EXE DEPENDS _ON MAIN.OBJ, SUB1.OBJ 


1 
! Object files and their sources 
! 

5) MAIN.OBJ DEPENDS ON MAIN.FOR 

© sup1.oBJ DEPENDS ON SUB1.NEW 


@ The first SUFFIXES list clears the default suffix list. If you do not clear 
the default suffixes list before adding a new file type, MMS appends 
the new file types that you add to the end of the list. This is risky 
because there is an implied hierarchy in the suffixes list. Adding a new 
type of a source code file to the end of the list works, but adding an 
intermediate file type to the end of the list destroys the order of the 
suffixes precedence list. 


@ This line contains the new suffixes list with all the file types used to 
build this system. 


© This is the user-defined rule for the new file type just added to the suffix 
precedence list. The command procedure NEW_COMPILER.COM is 
invoked to call the new compiler. 


© The new compiler compiles the source code file in MMS$SOURCE into 
an object file named by (MMS$SOURCE_LIST). 


A built-in rule is applied for compiling the FORTRAN code file. 
The new user-defined rule is applied for compiling and linking .NEW. 


© © 
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2.7.7 Building a System with a New File Extension 
To build your system with the description file NEW_SUFFIX, you must have 
the following files in your current directory: 


$ DIR/DATE=MODIFIED 


Directory DISK1: [BUILD] 


MAIN .FOR; 2 17-JUL~-1987 14:27 
NEW_COMPILER.COM; 5 17-JUL-1987 14:27 
NEW_SUFFIX.MMS;1 17-JUL-1987 14:27 
SUB1 .NEW; 1 17-JUL-1987 14:27 


Total of 4 files 


§ MMS/DESCRIPTION=NEW_SUFFIX 


FORTRAN /NOLIST/OBJECT=MAIN MAIN.FOR 
+1] @NEW COMPILER SUB1.NEW SUB1.OBJ 
LINK /TRACE/NOMAP/EXEC=MAIN MAIN.OBJ SUB1.OBJ 


@ MMS uses the new user-defined rule to compile the new language. 


Order of Suffixes 
The order of suffixes changes according to their use: 


¢ Ina dependency rule, the target is on the left and the source is on the 
right. 


¢ Ina suffixes list, the target is on the left and the source is on the right. 
e In a user-defined rule, the source is on the left and the target is on the 


right. 
2.7.8 Using the .SUFFIXES Directive with CMS Files 
If you add a rule in your description file that directs MMS to build a .FOR 


file by fetching it from a CMS library, the relationship between the rules and 
the file types might be as shown in Figure 2-2. 
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Figure 2-2: CMS Rules 
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Section 4.2 explains how to specify CMS elements in description files. (The 
tilde (~) signifies a file in a CMS library.) When MMS considers .FOR as 
a possible target, it discovers that a rule exists for building .FOR files from 
.FOR~ files. Therefore, it looks for a file named MOD3.FOR in the CMS 
library. If one exists, it applies the known rule to update the .FOR target; 
if it cannot find such a file, it continues searching for a file to use. If MMS 
does locate MOD3.FOR in the library, it can then use this file to create all 
the necessary sources that finally result in an updated MOD3.EXE, the 
original target. The simple dependency MOD3.EXE : could result in the 
following sequence of actions: 


MOD3.FOR DEPENDS ON MOD3.FOR~ 
CMS FETCH MOD3.FOR 


MOD3.OBJ DEPENDS ON MOD3.FOR 
FORTRAN/OBJ=MOD3 MOD3.FOR 


MOD3.EXE DEPENDS ON MOD3.OBJ 
LINK/EXEC=MOD3 MOD3.OBJ 


You can specify a null file type in the suffixes precedence list by using a free- 
standing period. For example, the following precedence list directs MMS to 
look for files with null file types before looking for .B32 files: 


-SUFFIXES .EXE .OBJ . .B32 


2.7.9 .INCLUDE Directive 


The .INCLUDE directive allows you to include other files in a description 
file. You can use this directive when you have stored common macros or 

user-defined rules in a separate file that can then be included by several 

description files. 
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The .INCLUDE directive has the following format: 
- INCLUDE filespec 


A filespec is a VMS file specification or a logical name that identifies the 
included file. The default file type is .MMS. 


The line in the description file on which the .INCLUDE directive occurs is 
replaced with the contents of the specified file. 


Included files may themselves include files, up to a depth of 16 or the 
maximum open file limit for your current process (as indicated by the 
FILLM quota) or whichever is less. MMS treats lines read from an included 
file as though they came from the original description file, except when it 
detects syntax errors. If an error occurs, the error message indicates the 
line number and the file in which the error was detected. 
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The .FIRST directive tells MMS to execute certain action lines before it 
executes the action lines that update the target. The .FIRST directive works 
with single or multiple targets. If you have selected multiple targets, then 
.FIRST is executed before the entire group of targets. 


The .FIRST directive has the following format: 


-FIRST 
action line... 


The action line is a command-language command that MMS executes before 
it updates the target. You can specify as many action lines with .FIRST as 
you like. 


MMS executes the action lines that accompany the .FIRST directive only 
if the target requires updating. The actions are executed before those that 
actually update the target. 


The following example shows how you might use .FIRST to send a mail 
message to your process to notify you when MMS begins processing your 
description file: 


-FIRST 
OPEN/WRITE MSGTEXT MSGTEXT.TXT 
WRITE MSGTEXT "Build of $(MMSSTARGET) now beginning" 
CLOSE MSGTEXT 
MAIL MSGTEXT.TXT ANDERSON - 
/SUBJECT="Report from MMS" 
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BOOK.MEM : CHAPTER1.MEM, CHAPTER2.MEM, CHAPTER3.MEM, CHAPTER4.MEM 
COPY/LOG CHAPTER1.MEM BOOK.MEM 
APPEND/LOG CHAPTER2.MEM BOOK.MEM 
APPEND/LOG CHAPTER3.MEM BOOK.MEM 
APPEND/LOG CHAPTER4.MEM BOOK.MEM 


CHAPTER1.MEM : CHAPTER1.RNO 
RUNOFF CHAPTER1 


CHAPTER2.MEM : CHAPTER2.RNO 
RUNOFF CHAPTER2 


CHAPTER3.MEM : CHAPTER3.RNO 
RUNOFF CHAPTER3 


CHAPTER4.MEM : CHAPTER4.RNO 
RUNOFF CHAPTER4 


When this description file (BOOK.MMS) is processed, the following lines 
appear on your terminal (or in your output file): 


OPEN/WRITE MSGTEXT MSGTEXT.TXT 

WRITE MSGTEXT “Build of BOOK.MEM now beginning" 
CLOSE MSGTEXT 

MAIL MSGTEXT.TXT ANDERSON /SUBJECT="Report from MMS" 
RUNOFF CHAPTER1 

RUNOFF CHAPTER2 

RUNOFF CHAPTER3 

RUNOFF CHAPTER4 

COPY CHAPTER1.MEM BOOK.MEM 

APPEND CHAPTER2.MEM BOOK.MEM 

APPEND CHAPTER3.MEM BOOK.MEM 

APPEND CHAPTER4.MEM BOOK.MEM 


2.7.11 .LAST Directive 


The .LAST directive tells MMS to execute certain action lines after it has 
executed the action lines that update the target. The .LAST directive works 
with a single target or with multiple targets. If you have selected multiple 
targets, then .LAST is executed after the entire group of targets. 


The .LAST directive has the following format: 


. LAST 
action line... 

The action line is a command-language command that MMS executes after 

it updates the target or targets. You can specify as many action lines with 

.LAST as you like. 


MMS executes the action lines that accompany the .LAST directive only 
if the target requires updating. The actions are executed after those that 
actually update the target. 
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2.7.12 
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The following example shows how you might use .LAST: 


A.EXE : A.OBJ 
LINK (GREGORY .OBJECTS]A.OBJ 


A.OBJ : A.FOR 
FORTRAN/LIST=[GREGORY.LISTINGS]A.LIS - 
/OBJECT=[GREGORY.OBJECTS] A.FOR 


- LAST 
SET DEFAULT [GREGORY .OBJECTS] 
DELETE/LOG A.OBJ;* 
SET DEFAULT [GREGORY. LISTINGS] 
PURGE/LOG A.LIS 


If A.LEXE needs to be updated, the LINK command is executed and produces 
an object file in the directory [GREGORY.OBJECTS]. If A.OBJ needs to be 
updated before it can update A.EXE, the FORTRAN command is executed 
and produces a listing in the directory [GREGORY.LISTINGS]. After A.EXE 
is up-to-date, the action lines associated with .LAST are executed to delete 
the object file and purge the listings directory. Notice the output that might 
be produced on your screen when you use the description file ADESC.MMS. 


$ MMS/DESCRIPTION=ADESC 

FORTRAN/LIST=[GREGORY.LISTINGSJA.LIS /OBJECT=[GREGORY.OBJECTS] A.FOR 
LINK [GREGORY .OBJECTS]A.OBJ 

SET DEFAULT [GREGORY.OBJECTS] 

DELETE/LOG A.OBJ;* 

SDELETE-I-FILDEL, USER$: [GREGORY]A.OBJ;1 deleted (3 blocks) 

SET DEFAULT [GREGORY.LISTINGS] 

PURGE/LOG A.LIS 

SPURGE-I-FILPURG, USERS: [GREGORY.LISTINGS]A.LIS;4 deleted (6 blocks) 


MMS allows you to perform a set of commands before or after all other 
actions through the use of the .FIRST and .LAST directives. The .FIRST 
and .LAST sections are executed only if MMS decides to take other actions 
to update a target. 


FDEF, .ELSE, and .ENDIF Directives 


The IFDEF directive tests whether a specified macro is defined. You use 
this directive to cause MMS not to process certain lines in your description 
file if the macro is undefined. 

The .IFDEF directive has the following format: 

- IFDEF macro 

(description file line]... 


- ENDIF 


Macro is the name of the macro being tested. The description file line is zero 
or more action lines that are valid in a description file. 
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The .IFDEF directive must always be accompanied by a matching .ENDIF 
directive. MMS checks for a definition of the macro specified with the 
.IFDEF directive. If the macro is undefined, all lines of the description file 
between .IFDEF and .ENDIF (even lines that contain IFDEF directives) are 
ignored. 


Consider the following description file, FORPROG.MMS: 


. IFDEF VAX 


A.OBJ : A.FOR 
FORTRAN A 


- ENDIF 
-IFDEF PDP11 


A.OBJ : A.FOR 
FORTRAN/PDP11 A 


- ENDIF 


When you invoke MMS with this description file, you can define one of the 
macros on the command line to determine which action line gets executed. 
For example: 


$ MMS/DESCRIPTION=FORPROG/MACRO="VAX" 
FORTRAN A /NOLIST/OBJECT=A.OBJ A.FOR 
LINK A.OBJ 

$ 


Because the command line defines the macro VAX, the command FORTRAN 
A is executed and the commands associated with the undefined macro 
PDP11 are ignored. 


You may use the .ELSE directive in conjunction with the IFDEF directive 
but never alone. If the specified macro for the .IFDEF directive is undefined, 
MMS skips all the subsequent lines of the description file until it comes 

to a .ELSE or a .ENDIF directive. The next example of a description file 
shows the format for a .[FDEF directive using .ELSE and a nested .IFDEF 
directive: 


. IFDEF VAX 

- IFDEF CURRENT 

A.OBJ : A.FOR 
FORTRAN A 

. ENDIF 

A.EXE : A.OBJ 
LINK A.OBJ 


- ELSE 

A.OBJ : A.FOR 
FORTRAN/PDP11 A 

- ENDIF 
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MMS reads the line beginning with the .FDEF directive and tests whether 
the macro is defined. If the macro is defined, MMS processes the action 
lines between .IFDEF and the second .ENDIF except for the lines between 
the .ELSE and the second .ENDIF-. If the specified macro for the .[FDEF 
directive is undefined, MMS skips all the action lines including the nested 
IFDEF, until it reaches the .ELSE directive. MMS then processes the 
subsequent lines to the .ENDIF. When you invoke MMS with the FORPROG 
description file, you can define the nested macro on the command line as 
follows: 


$ MMS/DESCRIPTION=FORPROG/MACRO="VAX=CURRENT" 
FORTRAN A 
$ 
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Chapter 3 


Advanced Description File Techniques 


Once you become familiar with MMS, you can use advanced techniques 
in your description file to make it more flexible and useful. This chapter 
describes the following techniques: 


¢ Double colon dependencies 

¢ Invoking MMS from a description file 

¢ Invoking MMS from a command procedure 

¢ Invoking a command procedure from a description file 
¢ Gathering statistics 

¢ Doing parallel processing 

¢ Producing multiple outputs 

e Changing build options 


3.1 Using Double Colon Dependencies 


In writing MMS dependency rules, you can specify the same target in more 
than one dependency rule, provided that you specify only one action for 
updating that target. For example, the following construction is legal: 
MOD2.OBJ, MOD3.OBJ : DEFS1.DEF 


MOD2.OBJ : DEFS2.DEF 
PASCAL MOD2 


MOD2.OBJ appears in the target list of two dependency rules, but only one 
action (PASCAL MOD2) is specified for it. 
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In contrast, the following construction is invalid: 


MOD2.OBJ, MOD3.OBJ : DEFS1.DEF 
PRINT DEFS1.DEF 


MOD2.OBJ : DEFS2.DEF 
PASCAL MOD2 


Two different actions are specified for MOD2.OBJ, requiring MMS to take 
two different actions if one of MOD2.OBJ’s dependencies is changed. 


If you want MMS to take different actions depending on which sources have 
changed, MMS allows you to use a double colon rather than a single colon 
to separate the target list from the source list in a dependency rule. (You 
can use the keyword ADDITIONALLY_DEPENDS_ON in place of the 
double colon.) For example, in the previous dependency rules, MMS was to 
execute the PRINT command if DEFS1.DEF had changed and the Pascal 
command if MOD2.PAS had changed. The double colon or the keyword 
ADDITIONALLY_DEPENDS_ON directs MMS to allow the same target to 
be specified in more than one dependency rule, each of which may require 
different actions to update the target. By using the double colon, you can 
modify the previous example to execute as you intended: 


MOD2.0OBJ, MOD3.OBJ :: DEFS1.DEF ! If at least one source is 


PRINT DEFS1.DEF ! newer than targets, print DEFS1.DEF 
MOD2.OBJ :: DEFS2.DEF ! If MOD2.PAS or DEFS2.DEF is newer than 
PASCAL MOD2 ! MOD2.OBJ, compile MOD2.PAS 


Note that in this example, if DEFS2.DEF or MOD2.PAS is newer than 
MOD2.OBJ and DEFS1.DEF, both action lines are executed. However, that 
is the normal behavior of MMS. In effect, double colons produce the same 
result as single colons, so their usefulness is limited. 


In a description file, a given target can be included either in a single colon 
dependency rule or in a double colon dependency rule, but not in both. MMS 
issues an error message if you try to specify both kinds of rules for the same 
target. 


3.2 Maintaining a Library of Object Files 


You can use MMS to maintain a library of object files. Consider the library 
called UTIL.OLB, which contains three object modules: MOD1.OBJ, 
MOD2.0BJ, and MOD3.OBJ. If one of these object modules is updated, it 
should be added to the library. A description file for this system might look 
like the following: 
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UTIL.OLB :: MOD1.OBJ 
LIBR UTIL.OLB MOD1.OBJ 


UTIL.OLB :: MOD2.OBJ 
LIBR UTIL.OLB MOD2.0OBJ 


UTIL.OLB :: MOD3.OBJ 
LIBR UTIL.OLB MOD3.OBJ 


UTIL.OLB depends on all three object modules, but MMS takes different 
actions depending on which module is out of date. However, library module 
file specifications are not allowed as targets in double colon dependency 
rules. For example, the following dependency rules cause MMS to perform 
the same actions as the previous examples but they are written with the 
single colon rule: 


UTIL(MOD1) : MOD1.OBJ 
LIBR UTIL.OLB MOD1.0OBJ 


UTIL(MOD2) : MOD2.0OBJ 
LIBR UTIL.OLB MOD2.0BJ 


UTIL(MOD3) : MOD3.OBJ 
LIBR UTIL.OLB MOD3.0OBJ 


When using the library module specification format, only the single colon is 
acceptable to MMS. 


3.3 Invoking MMS from a Description File 


When you invoke MMS, it runs two processes as it updates a target. The 
first process, your current process, executes MMS. The second process, a 
spawned subprocess, executes the action line you specified in the description 
file to update the target. MMS creates a spawned subprocess only when 
the target needs updating, and it creates only one spawned subprocess to 
execute all the actions in the description file. The subprocess is created 
when the first action is executed; it remains active until the MMS image 
- terminates. 


While a subprocess executes an action (such as a DCL command), the parent 
process waits until it is notified that the subprocess has finished executing 
commands. If you monitor the parent process, you may find it idle. 


You can invoke MMS from a description file while MMS is updating a target. 
Consider the following description file: 


MAIN.EXE DEPENDS ON MAIN.OBJ 
MMS/DESCRIPTION=TOOLS_LIB 
LINK MAIN.OBJ, TOOLS _LIB/LIB 


MAIN.OBJ DEPENDS ON MAIN.PAS 
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In this example, the executable file MAIN.EXE is rebuilt if MAIN.OBJ 
has been changed since the last build. However, before MMS performs the 
linking action, an MMS subprocess is invoked to rebuild and update the 
library if necessary. 


3.3.1 Using the $(MMS) Reserved Macro 


You can also invoke MMS from within a description file by specifying the 
reserved macro $(MMS) on an action line where you want MMS to be 
invoked again. 


When you invoke MMS from a description file with the $(MMS) reserved 
macro, another subprocess is used to execute the new invocation of MMS. 
The second invocation of MMS runs as a spawned subprocess that inherits 
any existing symbol definitions. The original subprocess is treated as a 
parent process for the subsequent MMS execution. 


As MMS processes the description file, it executes any action line that 
contains the reserved macro $(MMS), even if you specified the /NOACTION 
qualifier on the command line. ((NOACTION suppresses the execution of 
action lines and is described in the Command Dictionary.) Thus, the MMS 
subprocess is created but no other actions are performed. 


3.3.2 Process Quotas for MMS Subprocesses 


When a subprocess is created, the VMS operating system automatically 
assigns it a portion of the quotas established for your main process. Under 
heavily loaded systems, it is possible for the top-level MMS subprocess to 
complete before VMS has finished with the exit-cleanup code for the second- 
level MMS subprocess. If MMS tries to invoke another subprocess, you may 
receive the following error message: 


SMMS-F-DRVINSQUO, Your process needs a PRCLM of at least 2, current value is 0. 


In this case, you can increase your PRCLM quota or add the DCL WAIT 
statement in your description file. For example: 


IF FSSEARCH ("S$ (MMS$SOURCE)") .NES. "" THEN- 
DESCRIPTION = "/DESCRIPTION=$ (MMSSSOURCE) " 

- $(MMS) /NOSKIPS$ (MMSQUALFIERS) - 
/OVERRIDE/RULES=BUILD_COM:DESCRIP_BUILD- 
'DESCRIPTION’ $(MMS$SOURCE) 
WAIT 0:0:5 

- $(MMS) /NOSKIPS$ (MMSQUALIFIERS) - 
/OVERRIDE/RULES=BUILD_COM:PLI- 
/DESCRIPTION=$ (MMSSSOURCE) 
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3.3.3 Process Quotas for Using MMS 


To invoke MMS as a top-level process, you need the minimum process quotas 
shown in Table 3-1. 


Table 3-1: MMS Process Quotas 


Process Quota 

PRCLM A subprocess limit of 2 

FILLM An open file limit of 16 

BYTLM A buffered I/O byte limit of 8192 (nonrecursive) and 13000 (recursive) 
ASTLM An asynchronous trap limit of 25 


If you get the error message reflecting a “virtual memory exceeded” error, 
you may also need to increase your PGFLQUO (page file quota). If you use 
MMS recursively, that is, you invoke MMS from within an MMS process, 
then MMS requires even higher quotas. 


3.3.4 MMS Reserved Macros 


MMS includes two other reserved macros, $(MMSQUALIFIERS) and 
$(MMSTARGETS), which you can use when you invoke MMS as a subpro- 
cess. Both of these qualifiers pass to the subprocess the same information 
you specified on the command line that invoked MMS: 


¢ $(MMSQUALIFIERS) passes the command-line qualifiers. 
¢ $(MMSTARGETS) passes the targets from the command line. 


These two macros and $(MMS) are reserved macros; you cannot redefine 
them. 


The $(MMSQUALIFIERS) macro does not pass the (DESCRIPTION, 
/OUTPUT, /IGNORE, and /NORULES qualifiers. To use these qualifiers 
when invoking MMS from a description file, you must explicitly specify them 
after $(MMSQUALIFIERS), as shown in the following example: 


TESTS.EXE ; 
$(MMS) $(MMSQUALIFIERS) - 
/DESCRIPTION=[GREGORY]TESTBUILD - 
$ (MMSTARGETS) 
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If you do not use the $(MMSQUALIFIERS) macro, MMS uses the default 
qualifiers. A list of the default qualifiers and complete descriptions of all 
MMS qualifiers are contained in the Command Dictionary. 


The following example shows a description file, ALL.MMS, that contains two 
subprocess invocations of MMS: 


ALL.EXE : A.OBJ, B.OBJ 
LINK/EXEC=ALL A,B 


A.OBJ : 
$ (MMS) $(MMSQUALIFIERS) /DESCRIPTION=A A.OBJ 


B.OBJ : 
$ (MMS) $(MMSQUALIFIERS) /DESCRIPTION=B B.OBJ 


Before MMS can update the target, ALL.EXE, it must check the two sources, 
A.OBJ and B.OBJ, to make sure they are up-to-date. If either needs to be 
updated, MMS spawns a subprocess, using the specified description file. If 
both A.OBJ and B.OBJ need to be updated, the output from this example is 
the following: 


$ MMS/DESCRIPTION=ALL 
MMS /DESCRIPTION=A A.OBJ 
PASCAL A 

MMS /DESCRIPTION=B B.OBJ 
PASCAL B 

LINK/EXEC=ALL A,B 

$ 


If you invoke MMS with the /NOACTION qualifier and the same description 
file, the following output results: 


$ MMS/DESCRIPTION=ALL/NOACTION 
MMS /NOACTION /DESCRIPTION=A A.OBJ 
PASCAL A 

MMS /NOACTION /DESCRIPTION=B B.OBJ 
PASCAL B 

LINK/EXEC=ALL A,B 

$ 


The MMS subprocesses are created, but the PASCAL and LINK commands 


are not executed to update the targets because you specified /NOACTION on 
the MMS command line. 


3.4 Invoking MMS from a Command Procedure 


The previous description files have built software systems in a fixed way. 
You can build variations of your software system without modifying the 
description file by invoking MMS from a command procedure. The command 
procedure controls the actions MMS performs. You can use user-defined 
macros in a command procedure to change MMS’s default actions. 
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Some of the ways you can vary building your software systems can include 
the following: 


e Using /DEBUG versus /NODEBUG images 
¢ Producing listing files versus no listing files during compilation 
e Using /OPTIMIZE versus /NOOPTIMIZE during compilaton 


It is better to have the description file reflect the basic structure of your 
software system and use command procedures to produce variations in your 
build process. The description file should not be concerned with changing 
the details of compile and link options. 


Command Procedures and User-Defined Macros 


MMS has two types of built-in macros: default macros and special macros. 
MMS default macros stand for parts of built-in actions and can be over- 
ridden. MMS special macros stand for targets and sources and cannot be 
overridden. The special macros are defined when you invoke MMS and can- 
not be changed. Default macros are a set of string variables containing the 
names of VMS utilities and qualifiers. 


You can create a user-defined macro for a CLI symbol. With the /OVERRIDE 
qualifier, you can instruct MMS to use the value of the user-defined macro in 
your command procedure over the default value of the CLI symbol. Consider 
the command procedure, DEBUG_VERSION.COM, and the MMS description 
file SYSTEM1.MMS, shown in Example 3-1. 
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Example 3-1: Invoking MMS from a Command Procedure 


$ TYPE DEBUG_VERSION.COM 


$ ! 

$! 

$ ! Command procedure using the /OVERRIDE qualifier with MMS 
$ ! 

$ ! Create the user defined macros we want 

$! 

$ PFLAGS = "/LIST/NOOPTIM/DEBUG" 

$ LINKFLAGS = "/MAP/DEBUG" 
$ 

$ 

$ 

$ 

$ 

$ 

$ 


. 


! Invoke MMS and direct it to use our macros 
! 


© 


MMS /DESCRIPTION=SYSTEM1 /OVERRIDE 


Os TYPE SYSTEM1.MMS 


MAIN.EXE DEPENDS_ON MAIN.OBJ 
MAIN.OBJ DEPENDS ON MAIN.PAS 


PFLAGS and LINKFLAGS are CLI symbols with the same names as 
those of the default macros but set with new values. 


MMS with the /OVERRIDE qualifier is invoked from within the com- 
mand procedure to use the new CLI symbol values instead of the built-in 
default values. 


© The description file describes the dependencies. 


This example produces a software system very different from the one MMS 
would normally have built. The user-defined macro definitions in the com- 
mand procedure appear in the MMS output exactly where the default macro 
actions would have appeared. To invoke this command procedure you need 
the following files in your current directory: 


$ DIR/DATE=MODIFIED 


Directory DISK1: [BUILD] 


MAIN.PAS;3 18-JUL-1987 16:35 
DEBUG VERSION.COM;2 18-JUL-1987 16:35 
SYSTEM1 .MMS;1 18-JUL-1987 16:35 


Total of 3 files. 


$ @DEBUG VERSION 
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PASCAL /LIST/NOOPTIM/DEBUG MAIN.PAS 
LINK /MAP/DEBUG MAIN.OBJ 


MMS uses the user-defined rules to compile and link your program. 


3.5 Invoking a Command Procedure from a Description File 


You can invoke DCL command procedures from your description file. The 
following example describes a command procedure that loops until a given 
file becomes available. You can invoke that command procedure, called 
GETFILE.COM, from your description file as in Example 3-2. 


Example 3-2: Invoking a Command Procedure from a Description File 


STYPE GETFILE.COM 
$ LABEL: 
$ IF "'' PSSEARCH("!/P1! ")'" (NES. "" THEN GOTO DONE 
$ WAIT +:’P2’ 
$ GOTO LABEL 
S DONE: 
STYPE GET NEXT.MMS 
GET _NEXT_INFO : 
MAIL NL: $(MY_ PROC) /SUBJECT="string" 
@GETFILE ANSWER.IN 15 
@ANSWER.IN 
S$MMS/DECRIPTION=GET_NEXT 


You can use this command procedure when you start MMS in a batch job. 
ANSWER.IN corresponds to the P1 parameter, and 15 is the polling interval 
(in minutes) that corresponds to the P2 parameter. ANSWER.IN might 
modify the environment in some way. For example, it might set a CMS 
library at a point where MMS cannot find the right CMS library. 


The $(MY_PROC) macro in this description file is assumed to be a DCL 
symbol that represents a valid electronic mail address. 


NOTE 


Be sure you do not leave a space between the at sign (@) and the 
name of the command procedure, so that MMS does not interpret 
the at sign as the Silent action line prefix. 
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3.6 Changing System Build Options 


3-10 


During software development, the number of description files and major 
aspects of build procedures can change frequently. You can edit the 
command procedure to make the changes. As the MMS description file 
becomes stable, you can create a command procedure that prompts you 

for different system-building options. You can write a very complicated 
command procedure that asks you for compilation options, for link options, 
and for executable targets (when your description file has multiple targets). 
The command procedure can send you mail when the build is complete and 
move the results to another directory. You can also do some error checking 
for your input or add a default option for your input. 


The command procedure CHANGE_OPTIONS.COM, shown in Example 3-3, 
uses the DCL INQUIRE command to change compiling and linking options 
for a system build. 


Example 3-3: Command Procedure to Change Build Options 
$ TYPE CHANGE OPTIONS.COM 


Command procedure to vary build options for MMS 


! 
! 
! 
! Ask for compilation and linking options 

| 

INQUIRE PFLAGS "Enter PASCAL compilations options” 
INQUIRE LINKFLAGS "Enter link options" 

! 

! Invoke MMS and direct it to use new default macros 
1 


MMS /DESCRIPTION=SYSTEM1 /OVERRIDE 
\ 


MMMM MOMNUMNMNUMNUMNUNN 


$ TYPE SYSTEM1.MMS 


MAIN.EXE DEPENDS ON MAIN.OBJ 
MAIN.OBJ DEPENDS _ON MAIN.PAS 


@ Enter PASCAL compilations options: /LIST/NOOPTIM/DEBUG 
@ Enter link options: /MAP /DEBUG 
2] PASCAL /LIST/NOOPTIM/DEBUG MAIN.PAS 

LINK /MAP/DEBUG MAIN.OBJ 


(continued on next page) 
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Example 3-3 (Cont.): Command Procedure to Change Build Options 


© $s EDIT MAIN.PAS 
@s  e@cHANGE_opTIONS 


@ enter PASCAL compilations options: /NODEBUG/NOLIST 
@ enter link options: /NOMAP /NODEBUG 


@ PASCAL /NODEBUG/NOLIST MAIN.PAS 
e LINK /NOMAP/NODEBUG MAIN.OBJ 


The command procedure prompts you for compiling and linking options. 
The system is built using the options you supplied. 


The MAIN.PAS file is edited to force MMS to rebuild the system. If you 
invoked MMS again without changing anything, MMS would find the 
system up-to-date and take no action. 


©Os 


© The command procedure prompts you for options that change the way 
you built your system the last time. 


Note that if you change the way a system is built either by modifying the 
description file or by modifying the command procedure that calls it, MMS 
does not necessarily rebuild the system. MMS bases its actions on the dates 
of the software system itself. MMS does not compile or relink the system 
just because you added a user-defined macro to your description file or your 
command procedure. 


To invoke the CHANGE_OPTIONS command procedure, you need the 
following files in your current directory: 

$§  DIR/DATE=MODIFIED 

Directory DISK1: [BUILD] 


CHANGE OPTIONS .COM;1 

21-JUL-1987 15:51 
MAIN.PAS;3 18-JUL-1987 16:35 
SYSTEM1 .MMS; 1 18-JUL-1987 16:35 


Total of 3 files. 


$ @CHANGE_OPTIONS 
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3.7 Gathering Statistics 


The examples in the following sections describe the methods for using MMS 
to gather statistics about your files. 


3.7.1 Finding Missing Sources 


If you have stored the sources for your software system in a source directory 
or CMS library and you want to make sure all the sources are there, you can 
get a list of any missing files by inserting the .DEFAULT directive in your 
description file. For example: 


-DEFAULT : 
IF "’’FSSEARCH("MISSING.SRC")’" .EQS. "" THEN - 
COPY NL: MISSING.SRC 
OPEN/APPEND MSING MISSING.SRC 
WRITE MSING "missing $(MMSSTARGET_ NAME)" 
CLOSE MSING 


When you process this description file with MMS, MISSING.SRC contains 
the list of missing files. 


3.7.2 Creating a Checkpoint File 


You can use MMS to create a checkpoint file that indicates when MMS 
finishes building a target. For example, if your directory contains source 
files TEST1.C, TEST2.C, and TESTS3.C and you want MMS to create .EXE 
files from each of these sources and also to inform you when each target is 
complete, the following example shows a description file that accomplishes 
these tasks. This description file builds TEST1.EXE, TEST2.EXE, and 
TESTS3.EXE and creates a file called CHECK.PNT that indicates the time 
the executable files were completed. 


! Suffixes list with .PNT in the first position. 
. SUFFIXES 
.SUFFIXES .PNT .EXE .OBJ .C .C~ 


! User-defined rule to build .EXE files from .PNT files. 
-EXE.PNT : 
IF "’/’FSSEARCH ("CHECK.PNT")/" .EQS. "" THEN - 
COPY NL: CHECK.PNT 
OPEN/APPEND CHECK CHECK.PNT 
WRITE CHECK "Completed build of $(MMSSSOURCE) at '’fS$time()/’" 
CLOSE CHECK 
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MAIN TARGET : TEST1.PNT, TEST2.PNT, TEST3.PNT 
MAIL CHECK.PNT MICHAELS - 
/SUBJECT="Build summary of $(MMSSTARGET_NAME) ending at ‘’f$time()’" 
DELETE CHECK.PNT; 


NOTE 


The executable files will be built before the .PNT files are pro- 
cessed. The .PNT files are temporary files that allow the actions 
that produce the file to be localized in one place (the .EXE.PNT 
rule), 


When you run MMS, the action lines are displayed as follows: 


CC /NOLIST TEST1.C 

LINK /TRACE TEST1.0OBJ 

IF "’’FSSEARCH ("CHECK.PNT")’" .EQS. "" THEN COPY NL: CHECK.PNT 
OPEN/APPEND CHECK CHECK.PNT 

WRITE CHECK "Completed build of TEST1.EXE at '’fS$time()/" 
CLOSE CHECK 

CC /NOLIST TEST2.C 

LINK /TRACE TEST2.0OBJ 

IF "’’FSSEARCH ("CHECK.PNT")’" .EQS. "" THEN COPY NL: CHECK.PNT 
OPEN/APPEND CHECK CHECK.PNT 

WRITE CHECK "Completed build of TEST2.EXE at ’’fStime()’" 
CLOSE CHECK 

CC /NOLIST TEST3.C 

LINK /TRACE TEST3.OBJ 

IF "’’FSSEARCH ("CHECK.PNT")’" .EQS. "" THEN COPY NL: CHECK.PNT 
OPEN/APPEND CHECK CHECK.PNT 

WRITE CHECK "Completed build of TEST3.EXE at '’fStime()’" 
CLOSE CHECK 

MAIL CHECK.PNT MICHAELS/SUBJECT="Build summary of MAIN TARGET 
ending at ’’fStime()’" 

DELETE CHECK.PNT; 


The mail message sent to your process looks like the following: 


From: MICHAELS 21-FEB-1987 14:48 
TO: MICHAELS 
Subj: Build summary of MAIN TARGET ending at 21-FPEB~-1987 14:48:06.85 


Completed build of TEST1.EXE at 21-FEB-1987 14:47:32.99 
Completed build of TEST2.EXE at 21-FEB-1987 14:47:49.65 
Completed build of TEST3.EXE at 21-FEB-1987 14:48:06.33 





3.8 Creating and Using Time Stamps 


You can use MMS to create time stamps for such purposes as tracking the 
progress of the system and determining whether any sources have changed 
since the last time the system was built. 


You can use either DCL symbols or included files to create a time stamp. 
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3.8.1 Using DCL Symbols 


The following description file creates the file CMSMODS.RPT, which reports 
the number of modified sources by checking replace operations in the CMS 
library. 


PROJECT SOURCES = PARSE.Y, TOUCH.C, GM.C, DRIVE.C, CLP.C, - 
LEX.C, GRAFBUILD.C, GRAFWALK.C, LFS.C, - 
MACROBANK.C, MB.C, MMSPRINT.C, UTILS.C, - 
EXECCMD.C, RULES.C, LBR.C, CMSACCESS.C, - 
MMSMSG.MSG, FILTER.C, GRAPH.H, GLOBALS.H, - 
LBRDEF.H, PDEFS.H, TOKEN.H, CLP.H, TC.H 


! Special CMS filetypes not included by default. 
-SUFFIXES : .Y .Y~ 


! New CMS rules (Note: no real CMS fetches occur) 


-MSG~.MSG : 
COPY NL: $(MMSS$TARGET_NAME) .MSG ! Create the new time stamp file 
PUR $(MMSS$STARGET_ NAME) .MSG ! Remove the old one, if any 
MODS = MODS + 1 ! Increment the modification counter 

~-H~.H : 


COPY NL: $(MMSSTARGET_NAME) .H 
PUR $(MMSSTARGET_NAME) .H 
MODS = MODS + 1 


~C~.C : 
COPY NL: $ (MMS$TARGET_NAME) .C 
PUR $ (MMS$STARGET_ NAME) .C 

MODS = MODS + 1 


oY~.Y 3 
COPY NL: $(MMSSTARGET NAME) .Y 
PUR $(MMSS$TARGET NAME) .Y 
MODS = MODS + 1 
! Primary Target 

MODS : INIT $ (PROJECT SOURCES) 

IF "'!’FSSEARCH ("CMSMODS.RPT")’" .EQS. "" - 

THEN COPY NL: CMSMODS.RPT 
OPEN/APPEND CHECK CMSMODS.RPT 
WRITE CHECK "’’MODS’ MODIFICATIONS DETECTED AT /’’FSTIME()‘" 


CLOSE CHECK 


INIT : 

MODS = 0 
CMSMODS.RPT can be used in some form as input to a program that prints 
a graph of CMS replace operations with relation to a number of days. Such 
a graph can be used as an indication of how stable a given project’s source 
code is with respect to its milestones. 


It is a good idea to run a description file such as the one in this example on 
a daily or otherwise frequent basis. You may want to put the appropriate 
MMS command in your LOGIN.COM file. 
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3.8.2 Using Included Files 


Consider the following directories and files: 


{(DIR1) contains FILE1.X 
(DIR2] contains FILE2.Y 


([DIR3] contains FILE3.2Z 


MMS can build a file to report changes to these files. The following descrip- 
tion file creates the file CHANGES.DOC, which reports when changes were 
made to the source: 


- SILENT 
RECORD CHANGE = .INCLUDE CHANGE.REC 


REPORT_CHANGE : INIT FILE1.TIM FILE2.TIM FILE3.TIM 
IF "’’FSSEARCH("CHANGES.DOC")’" .NES. "" - 
THEN TYPE CHANGES.DOC 
IF "’’FSSEARCH("CHANGES.DOC")’" .EQS. "" - 
THEN WRITE SYSSOUTPUT "No changes detected" 


INIT : 
IF "’'FSSEARCH("CHANGES.DOC")’" .NES. "" —- 
THEN DELETE CHANGES .DOC; */NOLOG 


! Testing the time stamps 
FILE1.TIM : [DIR1]FILE1.X 
$ (RECORD_ CHANGE) 


FILE2.TIM : [DIR2]FILE2.Y 
$ (RECORD_CHANGE) 


FILE3.TIM : [DIR3]FILE3.Z 
$ (RECORD_CHANGE) 


Because the .SILENT directive suppresses the display of action lines, MMS 
displays one of two pieces of information when it processes this description 
file: 


¢ If no changes were made to the files, MMS prints “No changes detected,” 
as instructed in the REPORT_CHANGE action line. 


e If changes were made to the files, MMS displays the contents of the file 
CHANGES.DOC, as instructed in the REPORT_CHANGE action line. 
CHANGES.DOC lists the files that were changed and the times the 
changes were made. 
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CHANGE.REC, the file included by the RECORD_CHANGE macro, is the 
recording procedure (rule) for making a change. It contains the following 
actions: 


IF "!’FSSEARCH ("CHANGES.DOC")’" .EQS. "" = 
THEN COPY NL: CHANGES .DOC 
OPEN/APPEND CHANGE CHANGES.DOC 
WRITE CHANGE "Changes to $(MMSSSOURCE) noted ’’fStime()’" 
CLOSE CHANGE 
COPY NL: $ (MMSSTARGET_NAME) .TIM 
PURGE $ (MMSSTARGET_NAME) . TIM 


You can substitute different recording procedure files for CHANGES.REC 
without changing the description file every time. To do so, create the same 
description file described in the example, but omit the RECORD_CHANGE 
macro. Also, replace the invocations of the RECORD_CHANGE macro with 
-INCLUDE $(REC_PROC). After these changes, the description file appears 
as follows: 


- SILENT 


REPORT CHANGE : INIT FILE1.TIM FILE2.TIM FILE3.TIM 
IF "!’FSSEARCH("CHANGES.DOC")’" .NES. "" - 
THEN TYPE CHANGES.DOC 
IF "’’FSSEARCH ("CHANGES.DOC")’" .EQS. "" - 
THEN WRITE SYSSOUTPUT "No changes detected" 


INIT : 
IF "’’FSSEARCH ("CHANGES.DOC")’" .NES. "" = 
THEN DELETE CHANGES.DOC; */NOLOG 


! Testing the time stamps 
FILE1.TIM : [DIR1]FILE1.X 
- INCLUDE $(REC_PROC) 


FILE2.TIM : [DIR2]FILE2.Y 
. INCLUDE $(REC_PROC) 


FILE3.TIM : [DIR3]FILE3.2 
- INCLUDE $(REC_PROC) 


REC_PROC is a macro that you define on the MMS command line to be the 
name of a recording procedure file you want to use at the time. Type the 
following command line to use the file of your choice: 


$ MMS/MACRO="REC_PROC=@filename" 
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3.9 Deleting Files Selectively 


Usually after updating your system, you will want to delete the intermediate 
files from your working directory. Or you might want intermediate files to 
be deleted automatically after an MMS build. You can accomplish this task 
in three different ways: 


¢ Create a command procedure. 
e Use a macro definition. 
¢ Use the .LAST directive. 


The first two methods are described in the following sections. The use of the 
.LAST directive is described in Section 2.7.11. 


3.9.1 Using a Command Procedure 


To use a command procedure to delete files selectively, create the procedure 
in the description file. Modify the dependencies or the default rules to 
include the following actions: 


IF "/'FSSEARCH("DELETE.COM")’" .EQS. "" - 
THEN COPY NL: DELETE.COM 

OPEN/APPEND DEL_FILE DELETE.COM 
WRITE DEL_FILE "$ DELETE $(MMS$SOURCE) ;" 


NOTE 


Usually, you will want to modify only the .OBJ.OLB rule to 
include these actions. However, to delete everything, you can 
modify all the rules you use; take care that you are deleting only 
those files you want deleted. 


The modified .OBJ.OLB rule appears as follows: 


.OBJ.OLB : 

IF "’'FSSEARCH ("$(MMSSTARGET)")‘" .EQS. "" = 
THEN $(LIBR)/CREATE $ (MMSSTARGET) 

$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $ (MMSSSOURCE) 

IF "!/FSSEARCH ("DELETE.COM")’" .EQS.."" - 
THEN COPY NL: DELETE.COM 

OPEN/APPEND DEL FILE DELETE.COM 

WRITE DEL_FILE "$ DELETE $ (MMSS$SOURCE) ;" 
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Once you have modified the rule, add a target such as the following to your 
description file: 


DELETE : MYPROG.EXE ! The name of the target 
- @DELETE.COM 


Note that the Ignore action line prefix (-) is used to prevent MMS from 
aborting execution if it detects errors (such as the absence of files) while 
deleting files. 


To delete .OBJ files that MMS created during a build, you need type only 
the following: 


$ MMS/SKIP_INTERMEDIATE DELETE 


The /SKIP_INTERMEDIATE qualifier causes MMS not to rebuild the files 
that were deleted. 


3.9.2 Using a Macro Definition 


There are two ways of using macros for the selective deletion of files: 

e Use a macro definition on the MMS command line. 

¢ Use a DCL symbol as a macro. 

To use a macro on the command line to delete files, modify the desired rule 
to include the following action: 

IF "$(CLEAN)" .NES "" THEN DELETE $(MMSSSOURCE) ; 


Thus, the .OBJ.OLB rule appears as follows: 


.OBJ.OLB : 
IF "'’PSSEARCH ("S (MMSSTARGET)")’" .EQS. "" - 
THEN $(LIBR)/CREATE $ (MMSSTARGET) 
$ (LIBR) $(LIBRFLAGS) $(MMSSTARGET) $(MMSSSOURCE) 
IF "S(CLEAN)" .NES "" THEN DELETE $ (MMSSSOURCE) ; 


The command line is the following: 
$ MMS/CMS/SKIP/MACRO="CLEAN=CLEAN" 


You can equate the macro to any character string that you like; MMS simply 
needs to be able to expand the CLEAN macro to something other than the 
null string. 
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To use a DCL symbol as a macro for deleting files, add the same action line 
to the desired rule as for using a macro on the command line. However, 
substitute "CLEAN" for $(CLEAN), as follows, where CLEAN is a global CLI 
symbol: 


-OBJ.OLB : 
IF "’'FSSEARCH("S (MMSSTARGET)")/" .EQS. "" - 
THEN $(LIBR)/CREATE $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $ (MMS$SOURCE) 
IF "'’/CLEAN’" .NES "" THEN DELETE $(MMSSSOURCE) ; 


You can use the same macro definition on the command line as in the 
previous example. If you do not want to define the macro on the command 
line, make sure that the DCL symbol CLEAN is defined before you invoke 
MMS. Then the command line can be shortened as follows: 


S$ MMS/CMS/SKIP 


3.10 Using Parallel Processing 


If you have a large system to build, you can process different parts of it 
simultaneously by adding rules, such as the following, to the beginning of 
your existing description file: 


PARALLEL PROC : TARG1 TARG2 TARG3 ! Names for parts of your system 
! Files submitted 


TARG1 : 
MMS/CMS/OUT=TARG1.COM/NOACTION PROG.EXE 
SUBMIT $ (MMSSTARGET_NAME) 


TARG2 : 
MMS/CMS/OUT=TARG2.COM/NOACTION MOD.EXE 
SUBMIT S$ (MMSSTARGET_NAME) 


! The rules building the parts of your system 
PROG.EXE : PROG.OBJ 
action 


MOD.EXE : MOD.OBJ 
action 


This description file causes MMS to process the parts of your system “in 
parallel” or simultaneously, resulting in shorter processing time and earlier 
error detection. 
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3.11 Using MMS in Complex Examples 


This section demonstrates the following advanced uses of MMS: 


e A description file that uses object libraries 


¢ A description file that results in multiple outputs 


3.11.1 MMS and Object Libraries 


Example 3-4 contains a sample MMS description file using object libraries. 


Example 3-4: Description File Using Object Libraries 


t 

! DESCRIP .MMS 

t 

! This description file builds the INTERCOM facility. 
1O 

' 

! 

! Define macros for the following commands and built-in rules 
' 

DEBUG = /noDEBUG 

TRACE = /noTRACE 

LIST = /LIST=LISS: 

BFLAGS = $(LIST) $(DEBUG) /TERM=STAT 

MFLAGS = $(LIST) $ (DEBUG) 

CLDFLAGS = $(LIST) 

! LIBRFLAGS = /LOG 

LIBRE LAGS = 

LINKFLAGS = /FULL $(DEBUG) $(TRACE) /MAP=LIS$: 


! TNAME gives just the name portion of the target 
! 


TNAME = 'FSPARSE ("MMSSTARGET NAME",,, "NAME", "SYNTAX_ONLY") 
1 

! Define "built-in" rules 

1@ 

! 

- SUFFIXES ea 

. SUFFIXES : .EXE .OLB .OBJ - 


-B32 .BLI .MAR .CLD .L32 .R32 .REQ .SDL .MSG 


(continued on next page) 
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Example 3-4 (Cont.): 


Description File Using Object Libraries 


-B32.0BJ ; S$(BLISS) S$(BFLAGS) /OBJ=$ (MMSSTARGET) $ (MMSSSOURCE) 
-MSG.OBJ ; MESSAGE $(LIST) /OBJ=S(MMSSTARGET) $ (MMSSSOURCE) 
.MAR.OBJ 3; S(MACRO) S$(MFLAGS) /OBJ=$ (MMSSTARGET) $ (MMSSSOURCE) 
.CLD.OBJ 3; SET COMMAND /OBJECT=S (MMSSTARGET) $(CLDFLAGS) $(MMSSSOURCE) 
-REQ.L32 ; $(BLISS) /LIBRARY $(BFLAGS) /NOOBJ $ (MMS$SOURCE) 
.OBJ.OLB : 3] 

@ IF FSSEARCH (FSPARSE ("S$ (MMSSTARGET)") .NES. FSSEARCH ("S$ (MMSSTARGET) ") - 

THEN COPY/LOG $(MMSSTARGET) S$ (MMSSTARGET) 
@ IF FSSEARCH ("$(MMSSTARGET)") .EQS. "" - 


THEN $(LIBR)/CREATE/LOG $ (MMSS$STARGET) 
$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $(MMSSSOURCE) 


! Define groups of OBJs, how modules in 


| 
OLB ELEMENTS = 


NOTEFILE=OBJ$ : NOTEFILE.OBJ > 


CLASS=OBJ$:CLASS.OBJ 
ENTRY=OBJ$ : ENTRY .OBJ 


KEYWORD=OBJ$ : KEYWORD . OBJ 


NOTE=OBJS : NOTE. OBJ 


PROFILE=OBJ$ : PROFILE. OBJ 


USER=OBJ$: USER. OBJ 


CALLABLE_INTERCOM=OBJ$:CALLABLE_INTERCOM.OBJ 
CALLUSER=OBJ$ : CALLUSER. OBJ 
PARSEACT=OBJS : PARSEACT . OBJ 
INTERCOMTPU=OBJS : INTERCOMTPU. OBJ 


| 


FILEIO=OBJ$ : FILEIO.OBJ = 


.HANDLER=OBJS$ : HANDLER. OBJ 
ITEMSIZE=OBUJ$ : ITEMSIZE. OBJ 
ITEMLIST=OBJ$ : ITEMLIST.OBJ 
IDPARSE=OBJ$ : IDPARSE. OBJ 
INTERCOMMSG=OBJ$ : INTERCOMMSG. OBJ 
INTERCOMUTIL=OBJ$ : INTERCOMUTIL. OBJ 
INTERCOM$COMMAND_TABLE=OBJ$ : COMMANDS. OBJ 
INTERCOMSMAIN=OBJ$ : INTERCOMSMAIN. OBJ 
INTERCOMS SERVER=OBJS$ : INTERCOM$ SERVER. OBJ 


| 


TFRVEC=OBJ$ : TFRVEC . OBJ 


the OLB relate to OBJs 


(continued on next page) 
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Example 3-4 (Cont.): Description File Using Object Libraries 


I 

! Define the main targets. These are put in the kit. 
t 

MAIN TARGETS = = 

OBJ$: INTERCOMSSHARE.EXE, - 
OBJ$: INTERCOMSMAIN.EXE, - 
OBJ$:INTERCOMSSERVER.EXE, - 
OBJS: INTERCOMSSECTION.GBL, - 
OBJ$: INTERCOMSHELP.HLB, - 
SRC$:INTERCOM_INTERFACE.TPU, - 
SRCS$: INTERCOMSSTARTUP.COM, - 
SRCS$ : INTERCOMDCL. CLD 


Define dependency rules. 


Specify the main target(s) -- everything. 
This is the first dependency rule in this file; 
by calling this target "*", we can say "MMS *" at DCL level. 


GS So es ee SS 


$ (MAIN_TARGETS) 
CONTINUE 


t 

! Define the kit (this is not built by default) 

! Use "MMS OBJ$:INTERCOM_KIT" to build the installation kit. 
I 


OBJ$: INTERCOM_KIT : OBJ$:INTERCOM000.A 
CONTINUE 
OBJ$: INTERCOM000.A : $(MAIN_ TARGETS), SRC$:KITINSTAL.COM, SRC$:SPKITBLD.COM 


I 
- DELETE NNPS$: [INTERCOM. TEMP] *.*.* 
COPY $(MAIN_TARGETS),SRC$:KITINSTAL.COM NNP$: [INTERCOM. TEMP] 
@SRC$:SPKITBLD.COM $(TNAME) OBJS: NNPS: [INTERCOM. TEMP] *.* 
- DELETE NNPS$: (INTERCOM. TEMP] *.*.* 


! Build the documents (not built by default) 
' 


SPECS : OBJ$:INTERCOMPLAN.MEM, OBJ$: INTERCOMSPEC. MEM !'To say "MMS SPECS" at DCL 
CONTINUE 

OBJ$ : INTERCOMPLAN .MEM : SRCS$: INTERCOMPLAN.RNO 
COPY NL: SYSS$SCRATCH: INTERCOMPLAN.RNT !Create dummy file 


RUNOFF /INTERMEDIATE=SYSSSCRATCH: INTERCOMPLAN /NOOUTPUT SRC$: INTERCOMPLAN 
RUNOFF /CONTENTS /OUTPUT=SYSSSCRATCH: INTERCOMPLAN SYSSSCRATCH: INTERCOMPLAN 
RUNOFF SRCS$:INTERCOMPLAN /OUT=OBJ$ : INTERCOMPLAN 

~ DELETE SYS$SSCRATCH: INTERCOMPLAN. *; * 


(continued on next page) 
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Example 3-4 (Cont.): Description File Using Object Libraries 


OBJS$ : INTERCOMSPEC .MEM : SRCS$: INTERCOMSPEC.RNO 
COPY NL: SYSSSCRATCH: INTERCOMSPEC.RNT 'Create dummy file 
RUNOFF /INTERMEDIATE=SYSS$SCRATCH: INTERCOMSPEC /NOOUTPUT SRC$: INTERCOMSPEC 
RUNOFF /CONTENTS /OUTPUT=SYS$SCRATCH: INTERCOMSPEC SYS$SCRATCH: INTERCOMSPEC 
RUNOFF SRC$:INTERCOMSPEC /OUT=OBJ$ : INTERCOMSPEC 
- DELETE SYS$SCRATCH: INTERCOMSPEC. *;* 


! Build the executables and libraries 
{ 


$(LINK) $(LINKFLAGS) /SHAR=$ (MMSSTARGET) $(MMSSSOURCE) /OPT /NODEBU 5 ] 


LINK_SHR = 

LINK_EXE = $(LINK) $(LINKFLAGS) /EXEC=$ (MMSSTARGET) $(MMSSSOURCE) /OPT 

OBJ$ : INTERCOMS SHARE . EXE : SRCS:INTERCOMSSHARE.OPT OBJ$:INTERCOM.OLB ; $(LINK_SHR) 
OBU$ : INTERCOMSMAIN.EXE : SRC$: INTERCOMSMAIN.OPT OBJ$: INTERCOM.OLB ; $ (LINK_EXE) 
OBJS : INTERCOM$ SERVER. EXE : SRC$: INTERCOMS$SERVER.OPT OBJ$:INTERCOM.OLB ; $(LINK_EXE) 
OBJS$ : INTERCOMSSECTION. TPUSSECTION : SRCS: INTERCOM_INTERFACE. TPU 


DEFINE /NOLOG /USER INTERCOMSSECTION OBJ$: INTERCOMSSECTION 
- EDIT /TPU /SECTION=EVESECINI /NOJOURNAL /NODISPLAY /COMMAND=$ (MMSSSOURCE) 


OBUS : INTERCOMSHELP . HLB : SRC$: INTERCOMHELP .HLP 3) 
@ IF FSSEARCH (FSPARSE ("S$ (MMSSTARGET)")) .NES. FSSEARCH ("S (MMSSTARGET) ") - 
THEN COPY/LOG $(MMSS$TARGET) $(MMSSTARGET) 
@ IF FSSEARCH("S$ (MMSSTARGET)") .EQS. "" - 
THEN $ (LIBR) /CREATE/LOG/HELP $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) /HELP $(MMSS$TARGET) $(MMS$SOURCE) 


! Anything depending on INTERCOM.OLB is presumed to depend on all its modules. 
' 


OBJ$ : INTERCOM. OLB : OBJ$: INTERCOM.OLB($ (OLB ELEMENTS) ) 
CONTINUE 


! Any BLISS modules that REQUIRE ’INTERCOMREQ’ also depend on INTERCOMLIB.L32, 
! since it is referenced by INTERCOMREQ.REQ. We combine these two in a macro. 
1 


COM_REQ = SRCS$: INTERCOMREQ.REQ OBJ$: INTERCOMLIB.L32 





(continued on next page) 


Advanced Description File Techniques 3-23 


Example 3-4 (Cont.): 


! .B32 sources 

' 

OBJS$ :NOTEFILE. OBJ 
OBJ$: CLASS. OBJ 
OBJ$ : ENTRY. OBJ 

OBJS :NOTE.OBJ 

OBJS$ : KEYWORD. OBJ 

OBJ$ : PROFILE. OBJ 
OBJS : USER.OBJ 
OBJS : FILEIO.OBJ 

OBJS$ : HANDLER. OBJ 

OBJ$ : ITEMLIST.OBJ 

OBJ$ : ITEMSIZE.OBJ 

OBJ$ : INTERCOMUTIL. OBJ 
OBJ$ : IDPARSE. OBJ 

OBJS$ : CALLUSER. OBJ 

OBJS$ : PARSEACT. OBJ 

OBJS : INTERCOMTPU. OBJ 
OBJS$ : INTERCOMSMAIN. OBJ 
OBJ$ : INTERCOMS SERVER. OBJ 
OBJ$:CALLABLE_ INTERCOM. OBJ 


! .MAR sources 
t 


OBJ$ : TFRVEC.OBIJ 


! .REQ sources 
t 
OBJ$ :CXF.L32 


OBJS$ : USERDEF .L32 
1 


SRCS$:CXF.REQ 
SRC$ : USERDEF . REQ 


SRC$ :NOTEFILE.B32 
SRC$:CLASS.B32 
SRCS : ENTRY .B32 
SRC$:NOTE.B32 

SRC$ : KEYWORD .B32 
SRC$:PROFILE.B32 
SRC$ : USER.B32 

SRC$: FILEIO.B32 

SRC$ : HANDLER. B32 

SRC$: ITEMLIST.B32 

SRC$: ITEMSIZE.B32 

SRCS$: INTERCOMUTIL.B32 
SRC$: IDPARSE.B32 

SRC$ : CALLUSER. B32 

SRCS : PARSEACT.B32 

SRCS$ : INTERCOMTPU.B32 
SRCS$: INTERCOMSMAIN.B32 
SRC$ : INTERCOMSSERVER. B32 
SRC$:CALLABLE_INTERCOM.B32 


: SRC$:TFRVEC.MAR 


Description File Using Object Libraries 


$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 
$ (COM_REQ) 


! Several require files are combined to form a single BLISS library 


{ 
OBJS : INTERCOMLIB.L32 


SRC$: INTERCOMTRUC.REQ SRC$: INTERCOMMAC.REQ SRC$:RTN.REQ - 


OBJS : INTERCOMMSG.R32 OBJ$:NOTEITEMS .R32 
$(BLISS) /LIBRARY $(BFLAGS) /NOOBJ /NOLIST /LIBR=$ (MMSSTARGET) - 

SRCS$ : INTERCOMTRUC.REQ+SRC$ : INTERCOMMAC.REQ+SRCS$ :RTN.REQ+- 

OBJS : INTERCOMMSG. R32+OBJ$ : NOTEITEMS .R32 


! .MSG source 
t 


OBJS$ : INTERCOMMSG. OBJ 
! ,CLD sources 

! 

OBJS : COMMANDS. OBJ 


SRCS$ : INTERCOMMSG.MSG 


SRC$ : COMMANDS. CLD 
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OBJ$:CXF.L32 
OBJS$ : CXF .L32 
OBJ$ :CXF.L32 
OBJ$ :CXF.L32 
OBJ$ :CXF.L32 
OBJ$:CXF.L32 
OBJS :CXF.L32 


OBJS$ : USERDEF .L32 
OBJ$ : USERDEF .L32 
OBJS : USERDEF .L32 


OBJS$ : USERDEF .L32 


OBJS$ : INTERCOMLIB.1L32 
OBJ$ : INTERCOMLIB.L32 


@ The following logical names are used in this MMS file: 


SRC$ Directory containing all sources that can be modified 
OBJ$ Directory containing all machine-produced files 
LIS$ Directory containing listing files 


A simple command procedure is used to define these logical names. 
These can refer to the group-wide source directory or can be defined as 
a search list for a local copy of a module instead of the group-wide or 
shared module. The logical names were defined in either of the following 
formats: 


$ DEFINE SRCS$ NNPS$: [INTERCOM.SRC} 


$ DEFINE SRCS$ NNPS: [HILT.INTERCOM.SRC], NNP$: [INTERCOM.SRC] 


No CMS elements are explicitly mentioned in the MMS description 

file. Instead, NNP$:[INTERCOM.SRC] is specified as a CMS reference 
directory (see HELP CMS MODIFY LIBRARY /REFERENCE_COPY). 
Any module replaced in the CMS library causes a new version of the file 
to be put in this directory. 


All file references include the file directory to allow the MMS file to be 
used correctly from any default directory. Similarly, dependencies are 
explicitly described. 


@ Only the necessary suffixes were included in the suffixes list. This 
together with explicit specification of the dependencies should help MMS 
improve performance. 


© The rules for building an .OLB from .OBJ files (or an .HLB from .HLP 
files) takes search-lists into account. Only the first directory in the 
search-list is used to store the new .OBuJs. 


The default actions were redefined to allow you to use the entire source 
and target specifications instead of just the file name. For example, 
/OBJ=OBJ$:CLASS.OBJ was used instead of just /OBJ=CLASS. 


The first action line checks whether local .OLB is different from the 
first .OLB found by the search list. If so, the .OLB is copied to the local 
directory. The second line tests whether the .OLB really exists, and the 
third inserts the .OBJ into the .OLB. The first two lines are prefixed by 
@, so they are not echoed in the log files. 
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© The SPKITBLD command procedure builds a VMS installation kit. 
Creating an empty, temporary subdirectory as a staging area is neces- 
sary because SPKITBLD uses BACKUP to create the save-set. BACKUP 
would copy all versions instead of only the highest versions of the files. 


© Options files are used to build all the executable images. The LINK_ 
EXE and LINK_SHR macros are used to specify the actions and the 
qualifiers to produce the .EXE file. LINK_SHR overrides any /DEBUG 
qualifier that might be specified in LINKFLAGS. 


3.11.2 Producing Multiple Outputs with MMS 


Using MMS to describe and build systems that have actions with more 
than one output becomes complicated because MMS cannot express multiple 
output dependencies. Most actions involved in building a system have a 
single input and a single output. For example: 


ABC.OBJ DEPENDS ON ABC.FOR 
FORTRAN/NOLIST/OBJECT=ABC ABC.FOR 


This example contains the action line that uses the FORTRAN compiler to 
produce an object file from a FORTRAN source file. 


MMS can also describe cases in which multiple inputs are present. For 
example: 


ABC.OBJ DEPENDS ON ABC.FOR DEF.TXT 
FORTRAN/NOLIST/OBJECT=ABC ABC.FOR 


This example contains a source file, ABC.FOR, which contains an include 
file, DEF.TXT. Both files are needed to produce the object file, ABC.OBJ. 


However, MMS syntax cannot express the case in which multiple outputs 
are needed. For example, if you want to produce a listing of the compilation 
in the first example, you could use the following dependency and action 
lines: 


ABC.LIS ABC.OBJ DEPENDS ON ABC.FOR 
FORTRAN/LIST=ABC/OBJECT=ABC ABC.FOR 


This example does produce the correct results, in that valid listing and 
object files will be produced, but it does not produce the results correctly. 
The previous example is really a shorthand notation for the following: 


ABC.LIS DEPENDS_ON ABC.FOR 
FORTRAN/LIST=ABC/OBJECT=ABC ABC.FOR 


ABC.OBJ DEPENDS ON ABC.FOR 
FORTRAN/LIST=ABC/OBJECT=ABC ABC.FOR 
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You can assume that both the listing and object target appear as sources 
elsewhere in the description file. When you invoke MMS, both targets are 
built but the action line is triggered twice. This example produces the listing 
and object files redundantly and, therefore, violates the principle of minimal 
action of MMS. 


3.11.2.1. Independent Outputs 


In the previous example, you may consider the object and the listing files as 
independent. The compiler produces them independently and the revision 
time of the files is different. When the outputs are independent, it seems 
safe to produce them independently. You might describe their relationship in 
the following description file: 


ABC.LIS DEPENDS ON ABC.FOR 
FORTRAN/LIST=ABC/NOOBJECT=ABC ABC.FOR 


ABC.OBJ DEPENDS ON ABC.FOR 
FORTRAN/NOLIST/OBJECT=ABC ABC.FOR 


This example solves the problem of producing two listings and does produce 
correct results because no actions on listing and object files are sensitive 

to whether the files were created by the same operation. However, if a 
configuration change occurs (for example, the compiler is updated), and the 
object file ABC.OBJ is missing, then invoking MMS with this description 
file results in a new object file but no new listing file. This demonstrates 
that the files are not independent. You would normally expect that listing 
and object files are produced by the same operation. The files are consistent 
as long as they convey the same information (for example, compiler version 
indentification). 


3.11.2.2 Dependent Outputs 


The dependence of outputs is demonstrated clearly by the environment files 
and object files produced from a Pascal source file. Consider the following 
two Pascal source files, A.PAS and B.PAS: 


{A.PAS} 

{ INHERIT(’b’) ] PROGRAM a ; 
BEGIN 

bproc 

END. 


{B.PAS} 
MODULE b ; 
PROCEDURE bproc; 
BEGIN 
END; 
END. 


Advanced Description File Techniques 3-27 


When compiled and linked, these modules produce the executable image 
AB.EXE. Consider the dependencies in the following description file: 


AB.EXE DEPENDS _ON A.OBJ B.OBJ 
LINK/EXECUTABLE=AB.EXE A.OBJ, B.OBJ 


A.OBJ DEPENDS_ON A.PAS B.PEN 
PASCAL/OBJECT=A A.PAS 


B.OBJ DEPENDS ON B.PAS ; 
PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS 


This description file should work correctly but it is flawed. The file, B.PEN, 
never appears as a target. It is created when B.PAS is compiled and is then 
used as a source for creating A.OBJ. The description file would be more 
accurate if the B.OBJ dependency rule were changed as follows: 


B.OBJ B.PEN DEPENDS_ON B.PAS 
PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS 


This example does produce a redundant compilation, but at least the descrip- 
tion file is complete and consistent. However, under certain circumstances, 
the system does not link correctly because the linker checks that all refer- 
ences to an environment file are consistent. The linker does the checking 
with an “entity identification check,” which is inserted into object files that 
refer to an environment file. Because you cannot predict the order of com- 
pilation in all circumstances, MMS can produce object files referring to 
different environment files (with different identifications). The linker then 
sends the warning message ENTIDMTCH. 


If you attempt to produce the environment file separately, you may build the 
system incorrectly. For example, consider the following description file: 


B.OBJ DEPENDS _ON B.PAS 
PASCAL/NOENVIRONMENT=B/OBJECT=B B.PAS 


B.PEN DEPENDS ON B.PAS 

PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS 
In this example, an object file produced with the /NOENVIRONMENT 
qualifier does not contain the entity indentification check, and therefore 
strong typing across modules is defeated. 


3.11.3 Multiple Outputs Work-Around 


Because you cannot safely express the idea of multiple outputs in the 

source-target part of the dependency rule, you can modify the action line to 
produce safe results. It is safest to proceed from the redundant compilation 
description file. If you can avoid the extra compilation, then the description 


3-28 Advanced Description File Techniques 


file is complete and the resulting system is built correctly and with a 
minimum of actions. 


You can introduce a context variable into the action block to monitor 
whether the compilation has or has not been performed. Consider the 
following description file: 


AB.EXE DEPENDS ON A.OBJ B.OBJ 
LINK/EXECUTABLE=AB.EXE A.OBJ, B.OBJ 


A.OBJ DEPENDS ON A.PAS B.PEN 
PASCAL/OBJECT=A A.PAS 


B.OBJ B.PEN DEPENDS_ON B.PAS 
IF FSTYPE(B COMPILED) .EQS. "" THEN B_COMPILED=0 
IF .NOT. B COMPILED THEN- 
PASCAL/ENVIRONMENT=B/OBJECT=B B.PAS 
IF .NOT. B COMPILED THEN- 
B_ COMPILED=1 


In this example, B.OBJ and B.PEN are always produced by the same 
operation. However, the case in which B.OBd is missing still generates an 
inconsistency. You can avoid this only by introducing false information into 
the A.OBJ dependency rule as follows: 
A.OBJ DEPENDS ON A.PAS B.PEN B.OBJ 

PASCAL/OBJECT=A A.PAS 
In this example, MMS can guarantee that both B.OBJ and B.PEN must 
exist, and because of their coproduction they are simultaneously updated. 
The net effect of this work-around is to treat B.OBJ and B.PEN as one 
entity. 
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Chapter 4 


Accessing Libraries with MMS 


This chapter describes how you can specify sources and targets that are 
stored in libraries. The following sections describe how MMS can access or 
update information in the following types of libraries: . 


VMS libraries created with the LIBRARY utility 
VAX DEC/Code Management System (CMS) libraries 
VAX FMS libraries 

The VAX Common Data Dictionary (CDD/Plus) 

VAX Source Code Analyzer (SCA) libraries 


4.1 Creating and Accessing Files in VMS Libraries 


You can use MMS to access files that are contained in VMS libraries and to 
create library files using certain built-in rules. The built-in rules that MMS 
uses to create library files are listed in Section C.7 in Appendix C. These 
rules tell MMS to create the specified library if one does not already exist; 
they then cause MMS to replace the source module in the target library. 


NOTE 


You cannot use MMS to access modules in an RSX library because 
only a module’s revision date is recorded, not its revision time. 
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4.1.1 Formatting Library Module Specifications 


To specify that a source or target in a dependency rule is a module in a VMS 
library, use the following format. Avoid adding any spaces or tabs as they 
may cause problems in processing. 


library (module[=filespec], ... ) 


The library is a VMS file specification that denotes a library. The default file 
type is .OLB if you are referring to a module within the library. If you are 
referring to the entire library, there is no default file type. The module is the 
name of the module in the library. The filespec is the VMS file specification 
that corresponds to the module in the library. The default file type depends 
on the file type of the library. 


The format shown in this section describes how to refer to modules within 
a library. You can also use MMS to process the library file itself simply by 
providing the library file specification (for example, CRTLIB.OLB). 


There is a restriction in using library module specifications as targets in a 
double colon dependency rule. See Section 3.1 for more information. 


4.1.2 Using Logical Names in a Library Module Specification 


You can use a logical name for the name of the module if you supply the 
action lines that update the target. MMS cannot apply its built-in rules to a 
logical name because it relies on file types to determine which built-in rule 
is appropriate. 


For example, CRTLIB(C$STRLEN=STRLEN.OBJ) designates that the 
module C$STRLEN is in library CRTLIB.OLB; C$STRLEN is found in the 
file named STRLEN.OBJ. 


4.1.3 Specifying Multiple Modules 


You can specify multiple modules in the same library in two ways: 


¢ You can enclose the module names in one set of parentheses and sepa- 
rate them with commas. For example, to refer to three modules in the li- 
brary CRTLIB.OLB, you can specify CRTLIB(C$STRLEN=STRLEN.OBJ, 
C$STRPAD=STRPAD.OBJ, C$STRIND=STRIND.OB,J). 
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You can use the VMS * and % wildcard characters. For example, the 
specification CRTLIB(C$*) directs MMS to look for all modules in the 
library CRTLIB.OLB whose names begin with the characters C$. In 
the same way, the specification CRTLIB(C$STR%) directs MMS to look 
for all modules in CRTLIB.OLB whose names begin with the characters 
C$STR followed by only one character. 


4.1.4 Accessing Library Modules with Non-VMS File Specifications 


You can use a complete library specification when you need to access library 
modules whose names do not correspond to VMS file specifications (for 
example, C$6STRLEN=STRLEN.OBJ). However, MMS can interpret shorter 
specifications as follows: 


If the module’s name in the library is the same as its file name, you can 
provide just the module name in parentheses after the library name. For 
example, if the module in the previous example were named STRLEN, 
you could refer to the module in the library as CRTLIB(STRLEN). 


If the module’s file type is associated by default with the type of the li- 
brary, you can omit the file type. In the specification CRTLIB(STRLEN), 
MMS assumes that the file name is STRLEN.OBJ, because .OLB li- 
braries are assumed to contain .OBJ modules. If the module’s file type 
is something other than the default for that kind of library, you must 
supply the file type. For example, if the module were STRLEN.C, you 
would have to specify CRTLIB(STRLEN.C). MMS would then expand 
this specification to the following two dependencies: 


CRTLIB (STRLEN=STRLEN.OBJ) : STRLEN.OBJ 
STRLEN.OBJ : STRLEN.C 


4.1.5 Using Special Macros with Library Specifications 


When used with library specifications, certain MMS special macros have 
slightly different meanings: 


If a library is the source in a dependency rule, MMS$SOURCE expands 
to the complete specification of the module in the library. For example, 
in the specification CRTLIB(C$STRLEN=STRLEN), MMS$SOURCE 
expands to CRTLIB.OLB(C$STRLEN=STRLEN.OBJ). 


If a library is the target in a dependency rule, MMS$TARGET ex- 
pands to the name of the library. For example, in the specification 
CRTLIB(C$STRLEN), MMS$TARGET becomes CRTLIB. 
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¢ Ifa library is the target in a dependency rule, MMS$TARGET_NAME 
expands to the module name (without its file type). For example, if 
the library module is STRLEN, MMS$TARGET_NAME expands to 
STRLEN. 


In addition to these MMS special macros, there is another special macro, 
MMS$LIB_ELEMENT, which you can use only in library specifications. 
MMS$LIB_ELEMENT expands to the string between parentheses, that is, 
to the module name and its corresponding file specification. For example, 
in the specification CRTLIB(STRLEN), MMS$LIB_ELEMENT becomes 
STRLEN=STRLEN.OBJ. The expansion of MMS$LIB_ELEMENT does not 
depend on whether the library is the source or the target in a dependency 
rule. If the library is specified as both the source and the target, then the 
target is expanded. 


4.1.6 Using Libraries as a Source 


The use of libraries as a source is illustrated in the following example. 
Suppose your description file contains the following dependency rules: 


TOOLTITLE.EXE : SYSSLIBRARY:CRTLIB.OLB, USERS: [WATKINS]FLIB.OLB 
LINK TOOLTITLE.OBJ, SYSSLIBRARY:VAXCRTL/LIB, USER$: [WATKINS] FLIB/LIB 


TOOLTITLE.OBJ : SMGTEXLIB.TLB(SMGDEF=SMGDEF .H) 
CC TOOLTITLE + SMGTEXLIB/LIB 

TOOLTITLE.C is a C program that includes the file SMGDEF.H, which 

is stored in the text library SMGTEXLIB.TLB under the name SMGDEF. 

The action line in the second dependency rule invokes the C compiler to 

compile TOOLTITLE.C and the text library. You must state this action line 

explicitly. In this case, specifying only the target and source is not sufficient. 

The first dependency rule invokes the VAX Linker to link TOOLTITLE.OBJ 

with one system library and one user library. 


4.2 Using MMS with CMS 


If the VAX DEC/Code Management System (CMS) is installed on your 
system, you can use MMS to access elements in CMS libraries. CMS 
elements are denoted by the tilde (~). You should be familiar with CMS 
before you read this section. 


MMS provides default macros and special macros tailored for use with CMS. 
Appendix C lists the default macros and the special macros. 
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MMS can build your system software from source code files stored in CMS 
libraries. MMS fetches the source code file from its library, compiles the 
code into object files, then links the object files into executable images. MMS 
treats the CMS library as the source for your source code files. 


MMS treats the source code in your directory and an element in a CMS 
library, just as it does any other source or target pair. If the source code 
file in the default directory is missing, MMS fetches that element from its 
CMS library. If the source code file in the default directory is older than the 
library element, MMS fetches the element. Figure 4~1 illustrates a software 
system using CMS libraries. 


Figure 4-1: A Software System Using CMS Libraries 


MAIN.EXE 


MAIN.OBJ SUB1.OBJ 
MAIN.PAS SUB1.PAS 
MAIN.PAS~ SUB1.PAS~ 


ZK-5887-GE 
@ The executable file depends on the object files. 
@ The object files depend on the sources in the your directory. 





















© The sources in your directory depend on elements in CMS libraries. 
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MMS supports only one CMS qualifier: /GENERATION. The default macro 
CMSFLAGS expands to the (GENERATION qualifier. You can also specify 

/GENERATION and a generation number after the tilde (~) in the element 
name, as shown in this example: 


PROG.OBJ : [OTHER.CMS] PROG.C~/GEN=4A1 


The tilde format for an explicit reference to a CMS element is useful when 
you are certain that the most up-to-date source is stored in the CMS library. 
A more convenient use of MMS with CMS is to let MMS determine where 
the newest source is located and to fetch the CMS element automatically, 

if necessary. To take advantage of this feature, you must use the /CMS 
qualifier on the MMS command line and you should not use the tilde format 
for specifying the source. 


4.2.1 Using CMS Commands in a Description File 


You can use any CMS command in an MMS description file. 


As MMS examines target and source lines in your main process, it uses 
the CMS$LIB logical name to establish the CMS directory from which 
sources will be fetched if the target must be updated. If you use the CMS 
SET LIBRARY command in an action line, that command is executed in 
the subprocess where MMS normally executes action lines. Such an action 
establishes a new library as the current default for any subsequent action 
lines that execute CMS commands; however, the value of CMS$LIB is not 
changed in the main process because the CMS SET LIBRARY command 
is executed in the subprocess. MMS still looks for sources in the library 
represented by CMS$LIB. 


The MMS qualifier /REVISE_DATE has no effect when MMS is accessing 
elements in CMS libraries. 


4.2.2 Automatic Access of CMS Elements from Dependency Rules 


The /CMS qualifier directs MMS to look for sources in the current default 
CMS library, as well as in the directories specified in the description file. 

If the CMS element has been replaced in the library since the file in the 
specified directory was last revised, MMS directs CMS to fetch the source 
from the library so that the target can be rebuilt. MMS has built-in rules 
that instruct CMS how to find the correct source (see Section C.9 for the 
built-in CMS rules). MMS uses the sources fetched from CMS to update the 
target by executing the action lines in the description file. The CMSFLAGS 
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default macro determines which generation of an element is fetched as the 
source or from which class the source element is fetched. 


If the file in the specified directory is newer than the CMS element, MMS 
uses that file. Therefore, you could edit a source in your directory and build 
a new system with the edited source, rather than with the corresponding 
CMS element. 


For example, consider a description file that contains the following 
dependencies: 


A.EXE : A.OBJ 
A.OBJ : A.PAS 


If you invoke MMS with the /CMS qualifier, MMS processes the description 
file by looking in the current default CMS library for A.PAS. If it locates 
that source, it compares the revision time with the revision time of A.PAS in 
the current directory (if A.PAS exists there). If the CMS element is newer, 
MMS uses it to update A.OBJ. 


The CMSFLAGS default macro always fetches the most recent generation 
of an element on the main line of descent. You can redefine CMSFLAGS to 
indicate a specific element generation or the element generation that belongs 
to a particular class. However, if you do so, you must be aware that if newer 
generations exist in the library, they will not be fetched; MMS will check the 
time of the element designated by the CMSFLAGS macro against the time 
of the file in your directory. If the file is newer, MMS will use it even though 
more recent generations of the element may exist in the library. 


The /NOCMS qualifier directs MMS not to look automatically for sources 
in the current default CMS library; /NOCMS is the default. The /CMS and 
/NOCMS qualifiers are described in full in the Command Dictionary. 


4.2.3 Explicit References to CMS Elements in Dependency Rules 


The /CMS qualifier causes MMS to compare the times of a CMS element 
and a file in the specified directory, if both exist. You can also direct MMS to 
check only the CMS element by putting a tilde immediately after the source 
file name in a dependency rule. For example, the tilde in the following 
target or source line directs MMS to look for the source PROG.C in the 
current default CMS library: 


PROG.OBJ : PROG.C~ 


If you use the tilde format to indicate CMS elements, you can specify only 
one element in a given dependency rule. You cannot specify a list of CMS 
elements if their file specifications are followed by tildes. 
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If the element is in a CMS library other than the current default library, you 
must type the library specification before the element name: 


PROG.OBJ : [OTHER.CMS] PROG.C~ 


You may not be able to access elements in a CMS library that reside on a 
DECnet node other than your own. 


4.2.4 Using CMS Elements to Build the System 


The following example demonstrates how to build your software system with 
CMS elements. Consider the description file CMS_MMS.MMS, shown in 
Example 4-1. 


Example 4-1: Description File Using CMS Libraries 


$ TYPE CMS _MMS.MMS 


t 
! Executable target 
i] 


Q@wain.£xXE : MAIN.OBJ, SUB1.OBJ 
LINK $ (MMS$SOURCE_LIST) 


! 
: 


! Object files and their sources 
! 


@wain.oBg : MAIN.PAS 
SUB1.0OBJ ;: SUB1.PAS 
! 
! Where the sources are stored 
! 


@marn.pas : DISK1: [SYSTEM2_LIB]MAIN.PAS~ 
SUB1.PAS : DISK1: [SYSTEM2_LIB])SUB1.PAS~) 


@ The executable target is stated. 
@ The objects or targets are stated. 


© Each source code file has a target or source line. The element in the 
CMS library is the source. 
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You can build your system with the description file CMS_MMS.MMS, as 
shown in Example 4-2. 


Example 4—2: Building a System from CMS Library Elements 


Os DIR/DATE=MODIFIED 
Directory DISK1: [TEST] 


CMS_MMS .MMS;1 30-JUL-1987 13:10 


Total of 1 file. 
Qs MMS/DESCRIPTION=CMS_MMS 


mms$cmslib :== ’f$logical("CMSS$LIB") 
IF mmsScmslib .nes. "DISK1: [SYSTEM2_LIB]}" THEN 
CMS SET LIBRARY DISK1: [SYSTEM2_LIB] 


Ocus FETCH MAIN.PAS /GEN=1+ "" 
%CMS-S-FETCHED, generation 1 of element MAIN.PAS fetched 
IF mmsS$cmslib .EQS. "" THEN CMS SET LIBRARY 1234 
IF mmsScmslib .NES. "" .AND. mms$cmslib .NES. "DISK1: [SYSTEM2_LIB]" 
THEN CMS SET LIBRARY ‘mmsS$cmslib’ 
@pascan /NOLIST/OBJECT=MAIN MAIN.PAS 
mms$cmslib :== ‘f$logical("CMSSLIB") 
IF mmsScmslib -.nes. "DISK1: [SYSTEM2_ LIB]" THEN 
CMS SET LIBRARY DISK1: [SYSTEM2_LIB] 


Ocus FETCH SUB1.PAS /GEN=1+ "" < 
SCMS-S-FETCHED, generation 1 of element SUB1.PAS fetched 
IF mmsScmslib .EQS. "" THEN CMS SET LIBRARY 1234 
IF mmsScmslib .NES. "" .AND. mms$cmslib .NES. "DISK1: [SYSTEM2_LIB]" 
THEN CMS SET LIBRARY ‘mms$cmslib’ 
@pasca. /NOLIST/OBJECT=SUB1 SUB1.PAS 
@.INnK MAIN.oBJ, SUB1.OBJ 


Os DIR/DATE=MODIFIED 


Directory DISK1: [TEST] 


MAIN. EXE; 1 30-JUL-1987 13:19 
MAIN.OBJ;1 30-JUL-1987 13:19 
MAIN.PAS;1 30-JUL-1987 13:10 
SUB1.OBJ;1 30-JUL-1987 13:19 
SUB1.PAS;1 30-JUL-1987 13:10 


CMS_MMS.MMS;1 30-JUL-1987 13:10 


Total of 6 files. 


The default directory contains only the software description. 
MMS is invoked using the CMS_MMS.MMS description file. 


MMS fetches the missing source code file MAIN.PAS from CMS. Note 
that MMS fetches the latest generation of each element by using the 1+ 
notation. 


© MMS compiles the source code file MAIN.PAS. 


©o¢6 
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© MMS fetches missing source code file SUB1.PAS from CMS. 
© MMS compiles the source code file SUB1.PAS. 

@ MMS links the object files using the action line. 

© The default directory has a complete software system. 


MMS fetches sources from CMS if the source code file in your directory is 
missing or older. In this example, only the description file is in the default 
directory before you invoke MMS. There is no source code to compile in your 
default directory, but because the description file states the source of each 
source code file, MMS fetches the source code files from CMS. 


Because of the MMS built-in rule for accessing CMS libraries, MMS gen- 
erates more output when it fetches source files from CMS than when it 
builds a system with files from your directory. The extra actions reflected in 
the output are concerned with checking that the CMS library is set to the 
correct place before and after the fetch in case the source code is stored in 
more than one library. 


Appendix C contains a full list of extensions that MMS must know to fetch 
files from a CMS library and to access other libraries. 


4.2.5 Using CMS Libraries to Rebuild the System 


Rebuilding a system from a CMS library is similar to all other system 
rebuilding in that MMS first checks that all parts of the system are present 
and up-to-date and then re-creates executable files and object files that are 
old or missing. MMS also uses the CMS library as the source to update old 
and missing source code. 


Example 4-3 is an example of what can happen during the software 
development cycle. You reserve an element, fix a bug in the element, and 
test the fix before replacing the code element in the library. No one else has 
updated the library element since the last system build. 
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Example 4-3: Rebuilding Using CMS Libraries 


Os DIR/DATE=MODIFIED 


Directory DISK1: [TEST] 


MAIN 


MAIN. 


MAIN 
SUB1 
SUB1 


CMS _MMS.MMS;1 


Total of 6 files. 


-EXE;1 
OBJ;1 
-PAS;1 
-OBJ;1 
-PAS;1 


30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 


$ CMS SET LIBRARY DISK1: [SYSTEM2_LIB] 
SCMS-I-LIBIS, CMS library is DISK1: [SYSTEM2_LIB] 


@s cus RESERVE SUB1.PAS "Pixing a 
SCMS-S-RESERVED, generation 1 of 


@s EDIT SUB1.PAS 


$ PURGE 


Qs DIR/DATE=MODIFIED 


Directory DISK1: [TEST] 


MAIN 
MAIN 
MAIN 
SUB1 
SUB1 


CMS_MMS.MMS;1 


Total of 6 files. 


-BXE;1 
-OBJ;1 
-PAS;1 
-OBJ;1 
-PAS;3 


30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 
30-JUL-1987 


@s MMS/DESCRIPTION=CMS_MMS 


bug in stack handler" 
element SUB1.PAS reserved 


13; 
13% 
13: 
13; 
13: 
13: 


@pascaL /NOLIST/OBJECT=SUB1 SUB1.PAS 
LINK MAIN.OBJ, SUB1.OBJ 


ooo0o080 


You reserve a CMS element. 
You modify SUB1.PAS to fix a bug. 

One source code file SUB1.PAS is newer than its object SUB1.OBJ. 
You invoke MMS to rebuild the system. 

MMS rebuilds the system from files in your default directory fetch- 


15 


10 
13 
17 
10 


You have a complete, up-to-date system from a previous system build. 


ing nothing from the library. MMS compiles SUB1.PAS and links 
MAIN.OBJ and SUB1.OBJ. 
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When you invoke MMS in Example 4—38, MMS does not fetch any files from 
the CMS library. Nothing in your directory is missing and nothing is older 
than its library element. 


In the next example, you have a complete, up-to-date copy of the entire 
system in your directory. However, another person has updated one of the 
code files in the CMS library after you built your copy of the system. When 
you invoke MMS to see if your system is up-to-date, MMS detects the newer 
file in the CMS library and fetches the updated file from the library. It 
rebuilds the system using the newly fetched file. This demonstrates how 
MMS uses the CMS library as the source of your targets. Just as an object 
file is rebuilt if the code has changed, your file is updated if the library has 
changed. For example: 


@s viIR/DATE=MODIFIED 
Directory DISK1: [TEST] 


MAIN .EXE; 2 30-JUL-1987 13:15 
MAIN.OBJ; 1 30-JUL-1987 13:13 
MAIN.PAS;1 30-JUL-1987 13:10 
SUB1 .OBJ; 2 30-JUL-1987 13:13 
SUB1.PAS;3 30-JUL-1987 13:10 
CMS_MMS.MMS;1 30-JUL-1987 13:10 


Total of 6 files. 


@s ! (Another user reserves, changes and replaces MAIN.PAS) 


@s mms/DESCRIPTION=CMS_MMS 


mms$cmslib :== 'f$logical ("CMSSLIB") 

IF mmsScmslib .nes. "DISK1: [SYSTEM2 LIB]" THEN 
CMS SET LIBRARY DISK1: [SYSTEM2_LIB] 

@cms FETCH MAIN.PAS /GEN=1+ "" 

SCMS-I-FILEXISTS, file already exists, DISK1:[TEST]MAIN.PAS;2 created 

SCMS-S-FETCHED, generation 2 of element MAIN.PAS fetched 

IF mms$cmslib .EQS. "" THEN CMS SET LIBRARY 1234 

IF mms$cmslib .NES. "" .AND. mmsScmslib .NES. "DISK1: [SYSTEM2_LIB]" 
THEN CMS SET LIBRARY ‘mmsS$cmslib’ 

ASCAL /NOLIST/OBJECT=MAIN MAIN.PAS 

LINK MAIN.OBJ, SUB1.OBJ 


@ Your directory has a complete, up-to-date system. 

@® Another person updates a file in the project’s CMS library. 
© You invoke MMS to update your system. 

@ MMS fetches the newer source code in the library. 

© MMS compiles and links the newer source code. 
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When creating the “official” release of a software product, you want to be 
sure that the release is built from code in the library, not from test code that 
you may have in your default directory. It is better to create a [RELEASE] 
directory that is used only for building the system from its CMS libraries. 
No other operations are performed in that directory. 


4.2.6 Building a System from a Specified CMS Class 


You can build your system from a specified CMS class. Building with a class 
specifier in CMS is identical to building from current generations in CMS. 


In building a system from a specified CMS class, MMS still uses the CMS 
elements as the sources but it uses the designated class of generations, not 
necessarily the current generations. MMS allows you to find and modify old 
source code and re-create previous versions of your system by building from 
a specific CMS class. 


MMS looks for the description file on the main line of descent, un- 

less you override the default macro CMSFLAGS. If you specify 
/MACRO=“CMSFLAGS=/GENERATION<=class-name”, MMS instead uses 
the specified class. If MMS cannot find a description file in either your 
default directory or the CMS library, it aborts execution. 


You can use a user-defined macro to control the class that MMS fetches. The 
user-defined macro is used as a qualifier to one of MMS’s actions. For exam- 
ple, you define the macro CMSFLAGS, which contains the qualifiers MMS 
uses when it fetches an element from a CMS library. A /GENERATION 
qualifier on this macro causes MMS to fetch files from a certain class. 
Consider the command procedure BUILD_CLASS.COM and the description 
file SYSTEM3.MMS in Example 4—4. 
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Example 4—4: Description File for Building from a CMS Class 


Executable target 


@s tyYPE BUILD _CLASS.coM 
$ ! 
$ ! Command procedure to build any CMS class of SYSTEM2. 
$ ! 
$ ! Create the user defined macros we want 
$ ! 
@s INQUIRE CLASS "Enter name of class to build" 
Os CMSFLAGS = "/GENERATION=" + CLASS 
$ ! 
$ ! Invoke MMS and direct it to use our macros 
$ | 
Os MMS /DESCRIPTION=SYSTEM3 /OVERRIDE 
S$ !} 
@s type sysTEM3.MMS 
I 
1 
| 


MAIN.EXE : MAIN.OBJ, SUB1.OBJ, SUB2.OBJ 


LINK $(LINKFLAGS) $(MMS$SOURCE_LIST) 
1 
! Object files and their sources 
1 


MAIN.OBJ : MAIN.PAS 
SUB1.OBJ : SUB1.PAS 
SUB2.OBJ : SUB2.PAS 


{ 
: 


! Where the sources are stored 
1 


MAIN.PAS : DISK1: [SYSTEM3_LIB]MAIN.PAS~ 
SUB1.PAS : DISK1: [SYSTEM3_LIB]SUB1.PAS~ 
SUB2.PAS : DISK1: [SYSTEM3_LIB]SUB2.PAS~ 


@ The command procedure invokes MMS. 
12) 


The command procedure prompts you for the name of the CMS class to 
build. 


The CMSFLAGS macro (which is used by the built-in rule for fetching 
your source files) is set and the /GENERATION qualifier is added to the 


class name. 


The procedure invokes MMS with the /OVERRIDE qualifier so that your 
macro is used instead of the default. 


The description file lists where the source files are stored in the CMS 
library. 
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You can insert the MMS description file and its calling command procedure 
into the appropriate CMS class. In this way, the description file in a given 
class builds that class. As a system changes, you can continue to put a copy 
of the description file in each new class you create. 


4.2.7 Building a System from a Previous Class 


In this example, you build your system from a previous class in a directory 
that is empty except for the command procedure and the description file. 
MMS fetches files from CMS only if the library copy is newer than your copy. 
The files in the previous class are certain to be older than your code, so 
MMS does not fetch them unless you build the previous releases in a clean 
directory. For example, consider the system build shown in Example 4-5. 


Example 4-5: Building a System from a Previous CMS Class 


Os DIR/DATE=MODIFIED 
Directory DISK1: [VERSION13] 


BUILD CLASS.COM; 4 5-AUG-1987 13:17 
SYSTEM3 .MMS; 3 5-AUG-1987 13:09 


Total of 2 files. 
@s @surLp_cLass 


(continued on next page) 
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Example 4—5 (Cont.): Building a System from a Previous CMS Class 


@enter name of class to build: VERSION_1_ 3 


mms$cmslib :== '’f$logical ("CMSSLIB") 

IF mms$cmslib .nes. "DISK1: [SYSTEM3_LIB]" THEN 
CMS SET LIBRARY DISK1: [SYSTEM3_ LIB] 

$CMS-I-LIBIS, CMS library is DISK1: [SYSTEM3_ LIB] 


@cus FETCH MAIN.PAS /GEN=VERSION_1_ 3 we 
%SCMS-S-FETCHED, generation 2 of element MAIN.PAS fetched 
IF mms$cmslib .EQS. "" THEN - 
CMS SET LIBRARY 1234 
%CMS-E-NOREF, error referencing 1234 
~CMS-E-MUSTBEDIR, 1234 must be a directory specification 
%SCMS-W-UNDEFLIB, CMS library is now undefined 
IF mmsScmslib .NES. "" .AND. mmsS$cmslib .NES. "DISK1: [SYSTEM3 LIB]" ~- 
THEN CMS SET LIBRARY /mmsS$cmslib’ 
PASCAL /NOLIST/OBJECT=MAIN MAIN.PAS 
mmsScmslib :== 'fSlogical ("CMSS$LIB") 
IF mms$cmslib .nes. "DISK1:[SYSTEM3_LIB]" THEN 
CMS SET LIBRARY DISK1: [SYSTEM3_LIB] 
SCMS-I-LIBIS, CMS library is DISK1: [SYSTEM3_LIB] 


Ocus FETCH SUB1.PAS /GEN=VERSION_1 3 "" 
%SCMS-S-FETCHED, generation 1 of element SUB1.PAS fetched 
IF mmsScmslib .EQS. "" THEN - 
CMS SET LIBRARY 1234 
SCMS-E-NOREF, error referencing 1234 
-CMS-E-MUSTBEDIR, 1234 must be a directory specification 
%$CMS-W-UNDEFLIB, CMS library is now undefined 
IF mms$cmslib .NES. "" .AND. mmsScmslib .NES. "DISK1: [SYSTEM3_LIB]" 
THEN CMS SET LIBRARY ‘mmsS$cmslib’ 
PASCAL /NOLIST/OBJECT=SUB1 SUB1.PAS 
mmsScmslib :== 'f£Slogical ("CMSSLIB") 
IF mmsScmslib .nes. "DISK1: [SYSTEM3_LIB]" THEN - 
CMS SET LIBRARY DISK1: [SYSTEM3_LIB] 
SCMS-I-LIBIS, CMS library is DISK1: [SYSTEM3_ LIB] 


Ocus FETCH SUB2.PAS /GEN=VERSION_1_ 3 "" 
%$CMS~S-FETCHED, generation 3 of element SUB2.PAS fetched 
IF mmsS$cmslib .EQS. "" THEN - 
CMS SET LIBRARY 1234 
%CMS-E-NOREF, error referencing 1234 
-CMS-E-MUSTBEDIR, 1234 must be a directory specification 
%CMS-W-UNDEFLIB, CMS library is now undefined 
IF mms$cmslib .NES. "" .AND. mms$cmslib .NES. "DISK1: ([SYSTEM3_LIB]" - 
THEN CMS SET LIBRARY ‘mms$cmslib’ 
@pascat /NOLIST/OBJECT=SUB2 SUB2.PAS 
LINK/TRACE/NOMAP/EXEC=MAIN MAIN.OBJ, SUB1.OBJ, SUB2.OBJ 


Gs DIR/DATE=MODIFIED 
Directory DISK1: [VERSION13] 


(continued on next page) 
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Example 4—5 (Cont.): Building a System from a Previous CMS Class 


BUILD CLASS .COM; 4 5-AUG-1987 13:17 
MAIN.EXE;1 5-AUG-1987 13:22 
MAIN.OBJ;1 5-AUG-1987 13:21 
MAIN.PAS; 1 30-JUL-1987 13:22 
SUB1.OBd;1 5-AUG-1987 13:22 
SUB1.PAS;1 30-JUL-1987 13:10 
SUB2 .OBJ; 1 5S-AUG-1987 13:22 
SUB2.PAS;1 5-AUG-1987 13:12 
SYSTEM3 .MMS; 3 5-AUG-1987 13:09 


Total of 9 files. 


Your directory contains the command procedure and the description file. 
You invoke the command procedure. 
You enter the class name. 


MMS fetches all program code from the chosen class using the macro 
CMSFLAGS to override the default. 


The source code is compiled and linked normally. 


oo 60089 


Your directory contains the complete system. 


After you have built the previous version of your system, you can fix the bug 
you may have found. The following steps ensure a complete and accurate 
system: 

¢ Reserve the CMS element generation with the bug. 

e Edit the element to fix the bug. 

¢ Replace the CMS element as an alternate line of descent. 


e Replace the generation that was in the CMS class with the fixed version 
(CMS INSERT GENERATION /SUPERSEDE). 


Using Logical Names for CMS Library Specifications 


When writing CMS library specifiers in a description file, you can use logical 
names instead of a hard-coded device and directory name. This allows the 
exact location of the library to change, and can make the description file 
easier to read. The command procedure that invokes MMS can set the 
logical name (or perhaps it is set in a group or system logical name table). 
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4.2.8 Using the .INCLUDE Directive to Include CMS Files 


You can also use the tilde format with the INCLUDE directive to include 
files that are stored in the current default CMS library. For example: 


- INCLUDE RULES~ 


This line in the description file directs MMS to fetch the file RULES.MMS 
from the current CMS library. (The .INCLUDE directive is discussed in 
Section 2.7.9.) 


When a tilde occurs in your description file, MMS looks for the file in the 
current CMS library, even if you specify /NOCMS on the command line. 
However, if the CMS element is newer than the target in the dependency, 
the element is not fetched from its CMS library unless an action line directs 
CMS to fetch the source. 


4.2.9 Using a User-Defined Rule to Access a Single CMS Element 


The following example shows a user-defined rule for accessing a single-file 
CMS element: 


-C~.OBT : 
CMS FETCH $(MMSSCMS_ELEMENT) $(CMSFLAGS) $ (CMSCOMMENT) 
$(CC) $(CFLAGS) $ (MMS$CMS_ELEMENT) 


This dependency rule tells MMS to do the following: 


1. Fetch the .C source file from the current default CMS library, applying 
the qualifiers specified by the CMSFLAGS macro and writing to the 
CMS history file the remark specified by the CMSCOMMENT macro. 


2. Run the C compiler on the file fetched from the CMS library, applying 
the qualifiers specified by the CFLAGS macro. 


CMSFLAGS and CMSCOMMENT are default MMS macros. You can 
redefine them so that the same qualifiers or the same remarks are used for 
all accesses to CMS elements. 


4.2.10 Accessing a CMS Element Not in the Default CMS Library 


The next example shows how to access a CMS element that is not in the 
current default CMS library. 
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TEST.C : [OTHER.CMS] TEST.C~ 
CMS SET LIBRARY [OTHER.CMS] 
CMS FETCH TEST.C "Auto fetch from MMS" 


This dependency rule causes MMS to set the current default CMS library to 
[OTHER.CMS], fetch the element TEST.C, and write the specified remark 
to the CMS history file. (MMS does not reset the CMS library back to the 
default in this example. This action differs from that of the built-in rules for 
CMS element access. See Section C.9 in Appendix C.) 


4.2.11 Accessing Description Files in CMS Libraries 


If a description file does not exist in your default directory, and if you have 
defined a CMS library, you can request that MMS retrieve the description 
file from the CMS library by using the /CMS qualifier on the MMS command 
line. If the description file exists in your directory and is newer than the 
element in the CMS library, MMS uses the file in your directory. 


If you know that the description file you want to use is stored in a CMS 
library, you can explicitly request MMS to use that file. When you use 
the /DESCRIPTION qualifier on the MMS command line, you can fol- 
low the name of the description file with a tilde character so that MMS 
automatically fetches the file from the current CMS library. For example: 


$ MMS/DESCRIPTION=ALL~ 


This command directs MMS to fetch the description file ALL.MMS from the 
current CMS library. 


If the file you specify with /DESCRIPTION does not exist in the current 
CMS library, MMS issues an error message. 


4.3 Checking for Replacement of CMS Elements 


If more than one programmer is working on a project, you may want to 
wait for someone else to replace an element in the project CMS library 
before you do a particular task. MMS can automatically check for element 
replacements at specified intervals by using the command procedure in the 
next example. Besides the command procedure, you also need a description 
file that tells MMS which element to look for and how to notify you when 
the element has been replaced. Such a description file might be named 
THERE.TIM, as in the next example. | 
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THERE.TIM : NEEDED.FOR~ ! The name of the element 
IF "’'FSSEARCH ("THERE.TIM")’" .NES "" - 
THEN MAIL NL: ’FSGETJPI(" ", “USERNAME") /- 
/SUBJECT="$ (MMSSSOURCE) is back in the CMS library." 
SET DEFAULT 1234567890 ! Causes MMS to abort with $STATUS = failure 


The command procedure CHECKCMS.COM that loops until the specified 
element is available in the CMS library is as follows: 


CMS SET LIBRARY [LOUISE] ! The CMS library 

SET DEFAULT [LOUISE.WORK] ! Your working directory 

IF "’/’FSSEARCH("THERE.TIM")’" .EOS. "" THEN COPY NL: THERE.TIM 
LOOP: 

MMS /DESCRIPTION=THERE 

IF .NOT. SSTATUS THEN EXIT 

WAIT 0:5 ! or some interval 

GOTO LOOP 


MNONMUMMUHMNM 


When submitted to the batch queue, this command procedure runs MMS, 
which checks to see whether the element in the CMS library is newer than 
THERE.TIM. If it is not (that is, if the element has not been replaced in the 
CMS library), $STATUS is 1, and MMS waits the specified interval before 
trying again. If the element has been replaced, the first bit in $STATUS 

is 0, and MMS mails you the message “NEEDED.FOR is back in the CMS 
library.” 


You can run this procedure in a subprocess (instead of submitting it to the 
batch queue) by typing the following command: 


$ SPAWN/NOWAIT @CHECKCMS 


4.4 Accessing Forms in an FMS Library 


If VAX FMS is installed on your system, you can use MMS to access forms 
stored in FMS libraries. You should be familiar with FMS before reading 
this section. 


To specify an FMS form in a dependency rule, use the same syntax as for 
files in VMS libraries. This syntax is explained in detail in Section 4.1. The 
file type .FLB after the library name informs MMS that the library contains 
FMS forms. The default file type for FMS forms is .FRM. 


For example, consider the following dependency rule: 


A.FLB(B) : B.FRM 
$(FMS) $(FMSFLAGS) A.FLB B.FRM 


B.FRM is the source that updates the target B in the FMS library A.FLB. 
FMS and FMSFLAGS are default macros that invoke FMS with the 
/REPLACE qualifier. 


4-20 Accessing Libraries with MMS 


MMS uses the insertion time of a form in an FMS library to determine 
whether a source is newer than the target. You cannot use the /REVISE_ 
DATE qualifier with references to FMS forms. (See the Command Dictionary 
for a description of /REVISE_DATE.) 


4.5 Accessing Definitions in CDD/Plus 


If the VAX Common Data Dictionary (CDD/Plus) is installed on your system, 
you can use MMS to access records and other definitions stored in CDD/Plus, 
as long as the definitions have the revision time attribute. You should be 
familiar with CDD/Plus before reading this section. 


In a dependency rule, you follow the path name of a CDD/Plus definition 
with the caret (“) to inform MMS that the source is stored in CDD/Plus. 
For example: 


A.OBJ : A.PAS, CDDSTOP.B.C.D.E%* ! CDD record referred to in A.PAS 
PASCAL A.PAS 


In this example, the target A.OBJ resides in your current directory. 


MMS uses the CDD/Plus path specification to find the source and check its 
revision time against that of the target, ACOBJ. Then, MMS retrieves the 
revision time for the specified CDD definition. The definition must have the 
revision time attribute. If the definition is not found in CDD/Plus, MMS 
attempts to locate it at the specified path by using the CDD compatibility 
interface. In this case, MMS assumes that the definition is in a dictionary 
or subdirectory that has not yet been upgraded to CDD/Plus. If MMS cannot 
find the definition by using the CDD compatibility interface, it returns an 
error. 


CDD/Plus maintains a history list that includes the date and time that a 
CDD/Plus definition was accessed and an optional remark that you supply 
to document the access. To insert a remark in the CDD/Plus history list 
when MMS accesses a CDD/Plus definition, use the /AUDIT qualifier after 
the caret in the CDD/Plus specification. Follow the /AUDIT qualifier with 
a quoted string that contains the remark that is to be inserted in the 
CDD/Plus history file. For example: 


A.OBJ : A.PAS, CDDSTOP.B.C.D.E*/AUDIT="Accessed by MMS to update A" 

PASCAL A 
MMS writes the remark that follows the /AUDIT qualifier into the CDD/Plus 
history list for the specified definition. You must place the /AUDIT qualifier 
after the caret character; separate the qualifier from the remark with an 
equal sign or colon. You cannot use /AUDIT on the MMS command line. 
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MMS also provides the default macro CDDFLAGS. This macro is defined to 
be the null string, but you can redefine it so that the same remark is written 
to the history file for all accesses to CDD/Plus entities. For example, you 
could set up your description file as follows: 


CDDFLAGS = /AUDIT="Record accessed by MMS" 


A.OBJ : A.PAS, CDDSTOP.B.C.D.E% 
PASCAL A 


Q.OBJ : Q.PAS, CDDSTOP.L.M.N.O% 
PASCAL Q 


V.OBJ : V.PAS, CDDSTOP.W.X.Y.2% 
PASCAL V 


When MMS accesses one of these sources from CDD/Plus, it writes the 
string that is the value of CDDFLAGS into the history file. 


The following restrictions apply to CDD/Plus access: 


¢ You cannot use the /REVISE_DATE qualifier with references to 
CDD/Plus entities. (See the Command Dictionary for a description of the 
/REVISE_DATE qualifier.) 


¢ Information produced from using the /AUDIT qualifier is not examined 
during CDD/Plus node comparisons. 


¢ The /NOACTION qualifier has no effect on the /AUDIT qualifier. 
That is, if you have suppressed the execution of action lines with the 
/NOACTION qualifier, the remark you supply with /AUDIT is still 
written to the CDD/Plus history file. 


4.6 Using MMS with SCA 


When you specify the /SCA_LIBRARY qualifier, MMS generates an SCA 
library during the build process. Example 4-6 demonstrates how to use 
MMS with the /SCA_LIBRARY qualifier. 
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Example 4-6: Using MMS with the /SCA_LIBRARY Qualifier 


$ SET DEFAULT (SYSTEM1] 
$ SCA CREATE LIB [.SCALIB] 
$SCA-S-NEWLIB, SCA Library created in DISK1$: (SYSTEM1.SCALIB] 
$SCA-S-LIB, your SCA Library is DISK1$: {SYSTEM1.SCALIB] 
$ 
@s type sca.mMs 
PROG.EXE : PROG.OBJ 


PROG.OBJ : PROG.C 


$ 
Os TYPE PROG.C 
main () 
{ 
int total; 


total = 2 + 2; 
} 
$ 


Os MMS/SCA_LIBRARY/DESCRIPTION=SCA PROG.EXE 
CC /NOLIST/OBJECT=PROG/ANALYSIS_ DATA=PROG PROG.C 
mms$scalib = FSTRNLNM( "SCASLIBRARY") 
mms$scasetlib = 0 


IF mmsSscalib .EQS. "" .AND. "SCASLIBRARY:" .NES.-— 
"SCASLIBRARY:" THEN mms$scasetlib = 2 
IF mmsSscalib .NES. "" .AND. "“SCASLIBRARY:" .NES.- 


“SCASLIBRARY:" .AND. mmsSscalib .NES. "SCASLIBRARY:" THEN- 
mms$scasetlib = 3 
IF FSSEARCH ("SCASLIBRARY:SCASEVENT.DAT") .EQS. "" THEN- 
mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 
IF (mmsS$scasetlib .AND. 4) .EQ. 4 THEN SCA CREATE LIBRARY SCASLIBRARY: 
IF (mmsS$scasetlib .AND. 2) .EQ. 2 THEN SCA SET LIBRARY SCASLIBRARY: 
@s SCA LOAD PROG 
%SCA-S-LOADED, module PROG loaded 
%SCA-S-COUNT, 1 module loaded (1 new, 0 replaced) 
IF mmsS$scasetlib THEN SCA SET LIBRARY ‘'mmsS$scalib’ 
LINK /TRACE/NOMAP/EXEC=PROG PROG.OBJ : 
$ 


@ Set default to your system directory, and initialize the SCA library. 
A side effect of initializing the library is that the logical name 
SCA$LIBRARY is now defined. 


The MMS description file describing the system dependencies. 


The source code file that MMS uses to compile and link our target and 
sources. 


MMS/SCA_LIBRARY is invoked with the target PROG.EXE specified. 
SCA loads the SCA data file into the SCA library. 


oo O09 
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MMS 


Format 


MMS 


The MMS command invokes the VAX DEC/Module Management System. 
By default, it searches in your current directory for the description file 
DESCRIP.MMS. If DESCRIP.MMS does not exist, MMS then searches for 
a description file named MAKEFILE., and then for a file named target- 
name.MMS (see Section 1.2 and the (DESCRIPTION qualifier for more 


information). 


MMS //gualifier... ][target,... 


Qualifiers 

/[NOJACTION 
/CHANGED=(source1, source?2,...) 
/[NO]JCHECK_STATUS 
/[NO]CMS 
/[NO]DESCRIPTION|[=filespec...] 
/[NO]FORCE 
/[NO]FROM_SOURCES 
/HELP[="topic"] 
/[IDENTIFICATION 
/[NO]IGNORE[=options] 
/[NOJLIST[=filespec] — 
/[NO]LOG 

/MACRO=filespec 
/OUTPUT=filespec 
/[NOJOVERRIDE 
/[NO]REVISE_DATE 
/[NO]RULES[=filespec] 
/[NO]SCA_LIBRARY[=library-name] 
/[NOJSKIP_INTERMEDIATE 
/[NO]VERIFY 


Defaults 

/ACTION 

See text 
/NOCHECK_STATUS 
/NOCMS 
/DESCRIPTION[=filespec...] 
/NOFORCE 
/NOFROM_SOURCES 
See text 

See text 

/NOIGNORE 

/NOLIST 

/NOLOG 

See text 

See text 
/NOOVERRIDE 
/NOREVISE_DATE 
/RULES[=filespec] 
/NOSCA_LIBRARY 
/NOSKIP_INTERMEDIATE 
/VERIFY 
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Parameters 


/qualifier 

MMS qualifiers modify the MMS command. You can place qualifiers 
anywhere on the command line after the MMS command. The notation (D) 
following a qualifier indicates the default form. 


You can abbreviate all MMS qualifiers and their parameters, but you must 
be sure that the abbreviations are unique so they will not be confused with 
other command-line interface (CLI) qualifiers. If you type an ambiguous 
abbreviation, the CLI issues an error message. 


You can continue an MMS command to the next line by using the DCL 
continuation character, a hyphen (-), as the last character on the command 
line. 


target 
The name of a target, which can be either a VMS file specification, a logical 
name, a library specification enclosed in quotes, or a mnemonic name. 


Unless you use the /NODESCRIPTION qualifier on the command line, 

you need not type the qualifiers and targets you want to use. MMS 
assumes default qualifiers and updates the first target in the description file 
whenever you type the MMS command, or if you specified a target on the 
command line, MMS updates the target itself. 


Qualifiers 


/ACTION (D) 
/NOACTION 
Controls whether MMS executes the action lines in a description file. These 
qualifiers affect only the execution of action lines, not the behavior of MMS. 


The /ACTION qualifier displays action lines as they are invoked. MMS does 
not display any information on dependencies. 


If you specify /NOACTION, MMS does not execute the action lines, but 
instead writes them to an output file (either SYS$OUTPUT or the file 
specified by the /OUTPUT qualifier). /NOACTION is useful for determining 
what actions MMS would have executed had the system actually been built. 
You can also use /NOACTION in combination with the /OUTPUT qualifier 
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to generate a command procedure (see the description of the /OUTPUT 
qualifier). 


/NOACTION overrides the Silent action line prefix (@) described in 
Section 2.6.6. Note that the $(MMS) reserved macro is executed even if 
you specify /NOACTION. Therefore, you can see what actions MMS would 
have executed in the subprocess. See Section 3.3 for information about the 
$(MMS) macro. 


/NOACTION does not affect the /AUDIT qualifier that you can provide with 
references to CDD records. That is, if you suppress the execution of action 
lines with the /NOACTION qualifier, the remark you supply with /AUDIT is 
still written to the CDD history file. The /AUDIT qualifier and CDD records 
are described in Section 4.5. 


/CHANGED=(source1, source2,...) 

Directs MMS to treat only the specified sources as having been changed, 
regardless of their actual modification times. No date checking is performed 
at all; MMS simply rebuilds any targets that depend on one or more of the 
specified sources. This qualifier affects the behavior of MMS but not the 
execution of action lines. 


/CHECK_STATUS 

/INOCHECK_STATUS (D) 

Controls whether MMS returns a value in the symbol MMS$STATUS 
instead of updating a target. This symbol contains the status of the last 
action line executed by MMS. These qualifiers affect both the execution of 
action lines and the behavior of MMS. 


When you specify the /CHECK_STATUS qualifier, MMS checks whether a 
target is up-to-date by determining whether any actions would be executed if 
the /ACTION qualifier was specified. MMS issues an informational message 
and sets MMS$STATUS to 1 if no actions would be executed (that is, if 

the target is up-to-date). If the target needs to be updated, MMS sets the 
MMSS$STATUS value to 0. 


/CHECK_STATUS has precedence over both the /ACTION and /REVISE_ 
DATE qualifiers if they appear on the same command line. In this case, only 
/CHECK_STATUS is processed. 


The /NOCHECK_STATUS qualifier directs MMS to process the description 
file as it normally would, executing action lines if necessary. 
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/CMS 

/NOCMS (D) 

Controls whether MMS looks for source files, description files, and included 
files in the current default CMS library as well as in the specified directories. 
CMS must be installed on your system. See Section 4.2 for information on 
using MMS to access elements in CMS libraries. These qualifiers affect both 
the execution of action lines and the behavior of MMS. 


When you specify the /CMS qualifier and the source in the CMS library 
is newer, MMS fetches it from the CMS library. If the source in the CMS 
library is older, MMS instead uses the source in the specified directory. 


/CMS also directs MMS to look in the current default CMS library for a 
description file and any files included with the INCLUDE directive or 
specified with the (RULES qualifier. If MMS does not find a description file 
in either the specified directory or the current default CMS library, it aborts 
execution. 


The /CMS qualifier also directs MMS to apply CMS built-in rules where 
appropriate. (See Section C.9 for information about CMS built-in rules.) 


The /NOCMS qualifier directs MMS not to look in the current default 
CMS library for source files, description files, rules files, or included files. 
However, if any file specifications in the description file are followed by a 
tilde (~) to indicate specific CMS elements, MMS looks for the files in the 
CMS library regardless of whether /NOCMS is in effect. 


If you specify /NOCMS or the combination /CMS/NORULES, and the sources 
do not exist in the specified directory, MMS aborts execution. 


/DESCRIPTION[=filespec...](D) 

/NODESCRIPTION target 

Controls whether MMS looks for a description file to update the target. 
These qualifiers affect the behavior of MMS but not the execution of action 
lines. 


The filespec is a VMS file specification or a logical name that identifies the 
description file. The default file type is .MMS. If a tilde (~) follows the file 
specification, MMS fetches the description file from the default CMS library 
even if the description file exists in the default directory. The target is a 
VMS file specification or a mnemonic name that designates the target to be 
built. 
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When you specify more than one description file, separate the file spec- 
ifications with either commas (,) or plus signs (+) and enclose them in 
parentheses or quotation marks. 


If you use commas, the description files are processed separately and the list 
of files must be enclosed in parentheses. For example: 


$ MMS/DESCRIPTION=(A, B) 


If you use plus signs, the description files are concatenated and processed as 
one file. The list of files must be enclosed in quotation marks. For example: 


$ MMS/DESCRIPTION="A + B" 


You can combine separate description files with description files to be 
concatenated and processed as one file. For example: 


$ MMS/DESCRIPTION=("A + B", CLEANUP) 


This command line directs MMS to process AAMMS and B.MMS as one file, 
and CLEANUP.MMS as another. In this case, there are two default targets: 
the first one is in either A.MMS or B.MMS (depending on the contents of the 
two files) and the second one is in CLEANUP.MMS. 


If you specify a list of description files in parentheses and a list of targets, 
the rules for updating all the listed targets must occur in all the listed 
description files. For example: 


$ MMS/DESC=(A,B) X,Y,2Z 


In this case, the rules for updating X, Y, and Z must appear in both 
description files, AAMMS and B.MMS. 


If you specify a concatenated list of description files and a list of targets, 
the rules for updating all the listed targets must occur in the concatenated 
description file. For example: 


$ MMS/DESC="A + B" X,yY,Z 


In this case, the description file formed by the concatenation of AAMMS and 
B.MMS must contain the rules for updating X, Y, and Z. 


If you specify the (DESCRIPTION qualifier without a file specification 
or if you do not specify /DESCRIPTION, MMS looks first for the default 
description file DESCRIP.MMS. If it cannot locate that file, it looks for 
one called MAKEFILE; if it cannot find MAKEFILE., it looks for target- 
name.MMS. If MMS finds target-name.MMS, it does not update the first 


Command Dictionary CD-7 


MMS 


target in the description file, but instead attempts to directly update the 
target indicated by target-name.MMS. For example: 


S$ MMS MAIN. EXE 


In this example, if DESCRIP-MMS and MAKEFILE. are not present, MMS 
looks for a file named MAIN.MMS. If MAIN.MMS exists, MMS directly 
processes the target you specified on the command line, MAIN.EXE. See 
Section 2.1.2 for more information. 


If MMS cannot find any one of these files, it attempts to use built-in rules to 
build the target. 


If you use the /NODESCRIPTION qualifier, you must specify a target on the 
command line. /NODESCRIPTION directs MMS to ignore all description 
files and to build the target specified on the command line. 


/FORCE 

/NOFORCE(D) 

Controls whether MMS executes the action lines necessary to update one 
specific target. These qualifiers affect the behavior of MMS but not the 
execution of action lines. 


When you specify the /FORCE qualifier, MMS does not check whether the 
target or its sources are up-to-date, but simply rebuilds the specified target 
by executing the action lines. MMS also executes any .FIRST and .LAST 
directives associated with the target. 


The /FORCE qualifier is useful for quickly rebuilding a single target. 


/FROM_SOURCES 

/NOFROM_SOURCES (D) 

Directs MMS to build a target from its sources, regardless of whether the 
target is already up-to-date. This qualifier affects the execution of action 
lines and the behavior of MMS. 


When you specify the /FROM_SOURCES qualifier, MMS does not compare 
the revision times of the specified sources and target. Instead, it executes 
the action lines in the description file necessary to update the target. The 
/FROM_SOURCES qualifier is useful when you want to guarantee that an 
entire system is rebuilt, perhaps for an internal release. 
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If you specify the /CMS and /FROM_SOURCES qualifiers on the MMS 
command line, MMS uses the sources found in the default CMS library. If 
you do not use /CMS, MMS uses the sources found in the specified directory. 


The /FROM_SOURCES qualifier overrides the /SKIP_INTERMEDIATE 
qualifier. 


/HELP[="topic"] 
Provides information about MMS and its qualifiers. The topic is an MMS 
topic on which you want information. 


The /HELP qualifier displays information about MMS on your terminal. 

If you specify the /HELP qualifier without a topic, MMS displays general 
information and a list of qualifiers. To get help on a specific topic, type 
/HELP with an equal sign (=) and the topic. The topic must be enclosed in 
quotation marks. For example: 


$ MMS/HELP="/RULES" 


See Section 1.3 for more information. 


[IDENTIFICATION 

Directs MMS to display an informational message with the version number 
and copyright date of the MMS image you are running. MMS does not 
process any description files or qualifiers; it simply displays an informational 
message on your screen. 


You should include the version number and copyright date with any MMS 
Software Performance Reports (SPRs) you submit. 


/IGNORE[=options] 

/NOIGNORE (D) 

Directs MMS to specify the severity levels of errors that MMS normally 
ignores when it executes action lines. The parameters correspond to the 
DCL severity levels W, E, and F. The /NOIGNORE qualifier directs MMS to 
abort execution when it finds an error. These qualifiers affect the execution 
of action lines but not the behavior of MMS. 


The options field can contain the keyword WARNING, ERROR, or FATAL. 
WARNING directs MMS to ignore W errors and continue processing, but 
to abort execution if it finds either an E or an F error. If you specify the 
AIGNORE qualifier without parameters, WARNING is the default. ERROR 
directs MMS to ignore both W and E errors, but to abort execution if it 
finds an F error. FATAL directs MMS to ignore all errors, and to continue 
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processing the description file. This parameter is equivalent to the IGNORE 
directive. 


When you specify (IGNORE, the errors that MMS ignores are those 
generated by the execution of action lines rather than MMS errors. 
/IGNORE does not stop MMS error messages from being generated or 
displayed. Informational messages are always displayed, regardless of 
whether you use the /IGNORE qualifier. 


NOTE 


Take caution when executing MMS with the IGNORE qualifier; 
if errors occur during processing, the target may be updated but 
still contain errors of which you will not be aware. 


The .[GNORE directive and the Ignore action line prefix are similar to 
the /IGNORE=FATAL qualifier. However, instead of typing them on the 
command line, you include them in the description file. Sections 2.6.5 and 
2.7.1 describe the Ignore action line prefix and the IGNORE directive in 
detail. 


To override the .IGNORE directive contained in a description file, you must 
type the /IGNORE[=WARNING], /IGNORE=ERROR, or /IGNORE=FATAL 
qualifier explicitly on the MMS command line. You cannot override the 
Ignore action line prefix on the MMS command line. 


/LIST[=filespec] 

/NOLIST (D) 

Controls whether MMS writes dependencies and action lines to an output 
file as it processes the description file. These qualifiers affect the behavior of 
MMS but not the execution of action lines. 


When you specify the /LIST qualifier, MMS creates a complete listing of all 
dependencies, dependents, and actions that need to be processed to update 
the target. MMS creates this listing as it processes the description file, 
and writes the listing to the output file, or to SYS$OUTPUT if you did not 
specify a file. 


The /LIST qualifier is useful during the debugging of description files. You 
can also use /LIST in combination with the /NOACTION qualifier to display 
the dependency list and action lines without executing any actions. 
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/LOG 

/NOLOG (D) 

Controls whether MMS displays informational messages as it processes the 
description file. These qualifiers affect the behavior of MMS but not the 
execution of action lines. 


The /LOG qualifier directs MMS to write all informational messages to your 
terminal screen while it processes the description file. The /LOG qualifier is 
useful for debugging your description files. These messages indicate what 
MMS finds and what it assumes as it processes the description file. You 
should include these messages with any MMS Software Performance Reports 
(SPRs) you submit. To save these messages in a file, type the following: 


$ DEFINE SYSSOUTPUT MYFILE.LOG 
$ MMS/LOG 


$ DEASSIGN SYS$OUTPUT 


The /NOLOG qualifier prevents MMS from displaying informational 
messages. However, if you specify /NOLOG/CHECK_STATUS on the same 
command line, MMS does display the informational message that reports 
the value of MMS$STATUS. (See the description of the /CHECK_STATUS 
qualifier for more information about MMS$STATUS.) 


/MACROs=filespec | "macro", ... 

Directs MMS to add to or override the macro definitions in the description 
file. This qualifier affects the behavior of MMS but not the execution of 
action lines. 


The filespec is a VMS file specification or a logical name that identifies a file 
of macro definitions. The default file type is MMS. The macro string is a 
macro definition enclosed in quotation marks. Use the same format as for 
macro definitions in description files, that is, name = string. 


With the /MACRO qualifier, you can specify a macro definition on the MMS 
command line. You can also specify a file of macro definitions to use in your 
description file. Section 2.3 discusses the use of macros. 
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You can define macros in three locations: 


¢ Ina description file 
¢ Ina macro definitions file 


¢ On the command line 


To specify more than one macro definition on the MMS command line, 
enclose the list of macros in parentheses. For example: 


S$ MMS/MACRO=("A=MAC1", "B=MAC2") 


You can also specify both a macro definition and a file on the same command 
line. For example: 


$ MMS/MACRO=("A=MAC1", MACROS) 


/OUTPUT=filespec 

Directs MMS to write action lines and output to the specified file. Error 
messages preceded by “%MMS” are not written to this output file, but 
instead are written to SYS$ERROR. The /OUTPUT qualifier affects the 
behavior of MMS but not the execution of action lines. 


The filespec is a VMS file specification or a logical name that identifies the 
output file. The default file type is .LOG. If you do not specify the /OUTPUT 
qualifier on the MMS command line, MMS writes all action lines, messages, 
and output to SYS$OUTPUT. 


If you specify the /NOVERIFY qualifier on the same MMS command line 
with /OUTPUT, MMS does not write action lines to the output file. 


If you specify /OUTPUT and your command-line interpreter is DCL, MMS 
automatically prefixes a dollar sign ($) to any action line that does not 
begin with one. Thus, you can use the file generated by /OUTPUT as a DCL 
command procedure. 


/OVERRIDE 

/NOOVERRIDE (D) 

Controls the order in which MMS applies definitions when it processes 
macros. These qualifiers affect the behavior of MMS but not the execution of 
action lines. 
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- When you specify the /OVERRIDE qualifier, MMS overrides the macro 
definitions in the description file with CLI symbol definitions. To find the 
macro definitions that should have precedence, MMS looks at symbols 
defined by the CLI assignment statement, scanning the CLI symbol table 
for the body of the macro. If the body of the macro is not in the CLI symbol 
table, MMS substitutes a null string for all invocations of the macro. 


The /OVERRIDE qualifier imposes the following order of application when 
MMS processes macro definitions: 


1. Command line 
2. CLI symbol 

3. Description file 
4, Built-in 


Once MMS finds a definition for a macro, it does not search those locations 
farther down the list for more definitions. If MMS finds more than one 
definition in the same location (such as on a command line), it uses the last 
definition it processed, unless the location is a description file. MMS issues 
an error message if a macro is defined more than once in a description file. 


The /NOOVERRIDE qualifier imposes the following order, which is the 
default hierarchy: 


1. Command-line 
2. Description file 
3. Built-in 

4. CLI symbol 


/REVISE_DATE 

/NOREVISE_DATE (D) 

Controls whether MMS changes only the revision dates of all targets that 
need updating, or performs the update. These qualifiers affect the behavior 
of MMS, not the execution of action lines. 


When you specify the (REVISE_DATE qualifier, MMS changes only the 
revision dates of targets that need updating; it does not direct MMS to 
execute the action lines that actually do the updating. If any files are 
missing, /REVISE_DATE causes MMS to create them. If MMS cannot create 
a missing file, or if it cannot update the revision date of an existing file, it 
issues an error message. 
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The /REVISE_DATE qualifier is useful for reducing the number of super- 

fluous compilations, for example, when you change only a comment line in 
a required file. However, /REVISE_DATE can defeat the purpose of using 
MMS, so use this qualifier with caution. 


As it changes the revision times, MMS writes the name of the revised files 
to an output file (or to SYS$OUTPUT if no file is specified). If you specify 
the /REVISE_DATE and /NOVERIFY qualifiers, the names of revised files 
are suppressed. (Section 2.7.2 describes the .SILENT directive.) 


Unless you specify a target on the command line, the /REVISE_DATE 
qualifier causes MMS to revise the first target (and its sources) in the 
description file. If you specify multiple targets on the command line, those 
targets and their sources are revised. /REVISE_DATE does not change 
the value of MMS$STATUS. (See Section 2.6.3 for information about 
MMS$STATUS.) 


The /REVISE_DATE qualifier has precedence over the /ACTION qualifier if 
they both appear on the same command line. In that case, only /(REVISE_ 
DATE is processed. 


The /NOREVISE_DATE qualifier directs MMS to build the system by 
updating targets as necessary (as long as the /CHECK_STATUS qualifier is 
not specified on the same command line). 


/RULES[=filespec] (D) 

/NORULES 

Controls whether MMS applies user-defined built—in rules and a suffixes 
precedence list when it builds a system. These qualifiers affect the behavior 
of MMS but not the execution of action lines. 


The filespec is a VMS file specification or a logical name that identifies 

the file of user-created rules that MMS is to use. When you supply a file 
specification with the (RULES qualifier, MMS replaces the built-in rules it 
normally uses with the built—in rules and suffixes list in the file you specify. 
The file specified with /RULES has precedence over the file represented by 
MMS$RULES. 


If you specify /RULES without a file specification, MMS translates the 
logical name MMS$RULES to locate the user-defined built-in rules file. If 
MMS$RULES is not defined, MMS uses its own built-in rules. 
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The /NORULES qualifier prevents MMS from using its built—in rules or the 
suffixes precedence list. It also prevents MMS from applying user—defined 
rules and default macros. When you specify /NORULES, MMS applies only 
the dependency rules contained in the description file. 


/SCA_LIBRARY[=library—name] 
/NOSCA_LIBRARY (D) 
Controls whether MMS generates an SCA library during the build process. 


When you specify a library name with the /SCA_LIBRARY qualifier, MMS 
defines the macro $(SCALIBRARY) to be that library name. If you use 
/SCA_LIBRARY without specifying a library name, SCA$LIBRARY is the 
value of $(SCALIBRARY). If you do not specify /SCA_LIBRARY, /NOSCA_ 
LIBRARY is the default. 


The macro $(SCA) is defined to be SCA regardless of the setting of the 
/SCA_LIBRARY qualifier. 


The macro $(MMSQUALIFIERS) contains the setting of the /SCA_LIBRARY 
qualifier. 


When you specify the /SCA_LIBRARY qualifier, built-in rules for BASIC, 
BLISS-32, C, COBOL, FORTRAN, MACRO, Pascal, PL/I, and SCAN change. 
Table C-~2 lists the macros that change when you specify the /SCA_LIBRARY 
qualifier. 


NOTE 


You may prefer to defer the loading of modules into the SCA 
library until after all compilations are completed. In this case, 
you should define the default rules for compilation in your 
description file to be the same as the default rule provided by 
MMS when the /NOSCA_LIBRARY qualifier is specified. You 
should also include a .LAST directive, which then loads the SCA 
database. For example: 


-LAST : 


$(SCA) SET LIBRARY $ (SCALIBRARY) 
$(SCA) LOAD * 
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/SKIP_INTERMEDIATE 

/NOSKIP_INTERMEDIATE (D) 

Controls whether MMS builds intermediate source/target files. These 
qualifiers affect the behavior of MMS, not the execution of action lines. 


The /SKIP_INTERMEDIATE qualifier directs MMS to determine whether a 
target is up-to-date without rebuilding intermediate files unless they need to 
be updated. 


MMS first checks the target date against the dates of its sources. If the 
target is newer than its sources, MMS determines that the target does not 
need to be rebuilt; if MMS cannot find some intermediate files, it acts as 
though they already exist, and skips over them to check their sources, and 
so on. 


For example, if you have a .C file and an .EXE file, but no .OBJ file, and 
the time of the .EXE file is more recent than that of the .C file, the /SKIP_ 
INTERMEDIATE qualifier prevents MMS from building the .OBJ file and 
the .EXE file because the target is already up-to-date with regard to its 
nearest source. Using /SKIP_INTERMEDIATE saves time and disk space. 


If the target is older than its sources, MMS determines that the target does 
need to be rebuilt. It then ensures that all of the target’s immediate sources 
exist; if any do not, MMS works from the bottom up by first rebuilding the. 
missing sources, then rebuilding the target. If the sources contain included 
files that have changed, are located in a CMS library, or both, MMS also 
fetches the included files and recompiles the source files, then rebuilds the 
system. For example: 


! SYSTEM2.MMS 
! 


SYSTEM2 : MAIN.EXE, MOD.EXE 
MAIN.EXE : MAIN.OBJ 

MAIN.OBJ : MAIN.C, DEFS1.H, DEFS2.H 
MOD.OBJ : MOD.C, DEFS2.H 


If the included file DEFS1.H changes, when you specify the /SKIP_ 
INTERMEDIATE qualifier, MMS does the following: 


1. Determines that one of the target’s sources is newer than the target, and 
that the target must be rebuilt. 


2. Verifies that MAIN.OBJ depends on MAIN.C, which contains the 
included files DEFS1.H and DEFS2.H. 
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3. Fetches MAIN.C, DEFS1.H, and DEFS2.H from the CMS library and 
recompiles MAIN.C. 


4. Since MAIN.OBJ is now newer than MAIN.EXE, MMS rebuilds 
MAIN.EXE. 


5. Since none of the sources for MOD.EXE have changed, MMS does not 
need to fetch them from CMS, and target SYSTEM2 is now up-to-date. 


The /NOSKIP_INTERMEDIATE qualifier directs MMS to ensure that all 
intermediate source files exist and are up-to-date. If any intermediate 
source files do not exist, MMS builds them. This is the default. 


/VERIFY (D) 

/NOVERIFY 

Controls whether MMS displays action lines before executing them. These 
qualifiers affect the behavior of MMS, not the execution of action lines. 


The /VERIFY qualifier directs MMS to display each action line before 
executing it. MMS writes action lines either to SYS$OUTPUT or to a file 
you specify on the /OUTPUT qualifier. 


If you specify the /REVISE_DATE qualifier in combination with the /VERIFY 
qualifier, MMS displays the names of files whose dates have been revised. 


When you specify the /NOVERIFY qualifier, MMS suppresses the display 
(but not the execution) of action lines. Any error messages generated by 
the execution of action lines continue to be displayed. If you specify the 
/REVISE_DATE and /NOVERIFY qualifiers on the same command line, the 
names of files whose dates have been revised are not displayed. 


The behavior of the /NOVERIFY qualifier is identical to that of the Silent 
action line prefix and the .SILENT directive (see Sections 2.6.6 and 2.7.2, 
respectively). If a description file contains the SILENT directive, to override 
it you must type the /VERIFY qualifier explicitly on the MMS command line. 
You cannot override the Silent action line prefix from the MMS command 
line. 
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Error Messages 


This appendix lists messages produced by MMS. The messages are 
accompanied by explanations and suggested actions to recover from errors. 


A.1 Message Display 


MMS messages are issued on the current output device identified by the 
logical name SYS$OUTPUT. If you are running MMS interactively, this 
device is a terminal; if you are running MMS in batch mode, messages are 
written into the log file. 


A.2 Severity Levels 


The severity level of a message is included in the status message and 
indicates the general nature of the message. 


Informational (I) messages inform you of MMS’s actions during the system- 
building process. You can control the display of these messages by specifying 
the /[NO]JLOG qualifier on the command line (some informational messages 
are displayed regardless of whether you specify /LOG). 


Warning (W) messages indicate that MMS has encountered a minor 
error. If the error occurs during the execution of an action line, processing 
stops unless you specify the IGNORE=FATAL, /IGNORE=ERROR, or 
/IGNORE=WARNING qualifiers on the command line. 


Fatal (F') messages indicate that MMS is terminating because of a problem 
that prevents it from continuing any further. 


MMS does not generate Success (S) or Error (E) messages. : 
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A.3 MMS Messages 


This section lists all MMS messages along with brief descriptions and 
recommended user actions. Items enclosed in single quotation marks 
indicate variable information. 

ABORT, For target ‘target name,’ CLI returned abort status: %X’ status.’ 


Explanation: Execution of an action line in the description file re- 
turned a fatal or warning error. By default, MMS aborts execution. 


User Action: Correct the error in the action line. 


BADTARG, Specified target ‘target name’ does not exist in the description 
file. 


Explanation: You specified a target on the command line that 
does not exist in your description file. 


User Action: Correct the command line or the target specification 
in the description file. 


CDDACCERR, CODD access error on path ’ path specification.’ 


Explanation: The VAX Common Data Dictionary (CDD) signaled 
an error while attempting to access the path specified in your 
description file. 


User Action: Verify the path specification and correct the descrip- 
tion file. 


CDDNOAUD, CODD audit string not found. 


Explanation: You used the /AUDIT qualifier with a CDD element 
specification, but you did not supply a remark to be included in the 
CDD audit history file. 


User Action: Edit the description file to remove the /AUDIT 
qualifier or to include a remark with it. 


CDDNOTIME, CDD path ‘name’ has no time attribute. 


Explanation: The CDD path specification in your description file 
is not associated with a revision time. Therefore, MMS cannot 
determine whether the CDD element is newer than your target. 


User Action: You cannot use a CDD record that is not associated 
with a revision time. Correct the description file to specify a 
different CDD element. 
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CDDPLSERR, Error returned from CDD/Plus. 


Explanation: An error occurred in the processing of your de- 
scription file when MMS tried to access a CDD/Plus element. This 
message is preceded by a message from CDD/Plus to help you locate 
the error. 


User Action: Correct the condition that caused the first error and 
try again. 
CDDPRIERR, Prior severe CDD error has occurred. 


Explanation: An error occurred earlier in the processing of your 
description file when MMS tried to access a CDD element. This 
message is preceded by one of MMS’s other error messages that 
pertain to the CDD and by a message from the CDD itself to help 
you locate the error. 


User Action: Correct the condition that caused the first error and 
try again. 


CLPHELP, Please type HELP MMS for help on DEC/MMS. 


Explanation: For some reason MMS cannot access the help 
library from the /HELP qualifier on the MMS command. 


User Action: Type the DCL command HELP MMS instead. 
CMSABORT, Aborted with CMS errors. 


Explanation: One or more errors were returned by Callable CMS 
and MMS cannot continue processing. 


User Action: The CMS message printed after %MMS-W- 
CMSCALL will describe what caused the problem. Refer to the 
Guide to VAX DEC /Code Management System for more information. 


CMSBADGEN, Illegal generation ‘value’ specified in description file. 


Explanation: The generation value specified by the /GENERATION 
qualifier is not valid. 


User Action: Correct the generation value or the CMS library. 


CMSBADLIB, There is a problem with the specified CMS library ' library 
name.’ 


Explanation: MMS is unable to access the specified CMS library. 
User Action: Correct the CMS library or the description file. 
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CMSBADTIM, Invalid time field in CMS history file for file ‘ filespec.’ 


Explanation: The time field in the history portion of the file in the 
element is in a nonstandard format. 


User Action: Reserve and then replace the CMS element that 
contains the specified file. If this element belongs to a specified 
CMS class, perform the steps necessary to replace the newly 
created generation of that element into that CMS class. 


CMSCALL, Callable CMS has returned an error. 


Explanation: Callable CMS, used in conjunction with CMS 
Version 2 libraries, has returned an error to MMS. The specific 
error is printed on the next line. 


User Action: Refer to the Guide to VAX DEC/Code Management 
System for more information on the CMS error returned. 


CMSNOCLAS, Specified class name ‘name’ not found in CMS library 
‘library name.’ 


Explanation: MMS could not find the given class name (specified 
with /GENERATION in the CMS library). 


User Action: Correct the CMS library or the description file. 


CMSNOELE, Element ‘element name’ not found in CMS library. 


Explanation: MMS could not find the specified element in the 
CMS library. 


User Action: Correct the CMS library or the description file. 


CMSNOFIL, File ’filespec’ not found in CMS library. 


Explanation: MMS could not find the specified file in the CMS 
library. 


User Action: Correct the CMS library or the description file. 


CMSNOGEN, No generation value specified. 


Explanation: You did not specify a value with the /GENERATION 
qualifier. 


User Action: Add the value to the /(GENERATION qualifier. 
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CMSNOLIB, Your default CMS library is undefined. 


Explanation: You do not have a CMS library defined but you used 
/CMS on the command line or a tilde (~) in the description file. 


User Action: Define a CMS library. 


CMSNOSUP, DEC/MMS cannot access DEC/CMS, or DEC/CMS is not 
installed. 


Explanation: You are trying to access a source in a CMS library, 
but MMS was installed without CMS support. 


User Action: CMS must already be installed on your system 
before you install MMS if you want access to CMS libraries. 


CMSPROBLEM, Problem with CMS control file ’ filespec.’ 


Explanation: The specified control file is either missing or has 
been opened by another user without using CMS. 


User Action: Check to see whether the file is in the specified CMS 
library. If it is, make sure it is closed and try running MMS again. 
If the file is not in the CMS library, correct the library. 


CMSPROCED, Proceeding with CMS library access. 
Explanation: MMS is now accessing the specified CMS library. 


User Action: None. This is an informational message that ap- 
pears after the CMSWAIT message when MMS finally succeeds in 
accessing the library. 

CMSWAIT, CMS library ‘library name’ is in use. Please wait... 


Explanation: The specified CMS library is currently being ac- 
cessed by another user. This message is printed at 4-second 
intervals until access is successful. 


User Action: Wait until MMS succeeds in accessing the CMS 
library. 
DRVBADPARSE, Parser detected a fatal syntax error in the description 
file. : 


Explanation: The description file contains a syntax error. MMS 
did not attempt to build the system. 


User Action: Correct the erroneous line in the description file. 
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DRVDEPFIL, Using description file ’ filespec.’ 


Explanation: MMS is using the specified description file to build 
the system. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVFMSSUP, DEC/MMS is installed with support for VAX FMS. 


Explanation: You can access forms stored in VAX FMS libraries 
with this version of MMS. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVINSQUO, Your process needs a ‘quota name’ of at least ' value,’ 


current value is ’ value.’ 


Explanation: At least one of the process quotas set by your system 
manager has been exceeded, and the remaining process quotas at 
the time MMS was invoked were insufficient to ran MMS reliably. 
The BYTLM value relates to the buffered I/O byte count quota; 
the ASTLM value relates to the AST limit of your process; the 
PRCLM value relates to the subprocess limit of your process; and 
the FILLM value relates to the open file limit of your process. You 
can obtain information about your process-specific parameters by 


typing the DCL command SHOW PROCESS/QUOTA. 


User Action: Request that your system manager increase process 
quotas. 


DRVNOFMSSUP, DEC/MMS is installed without support for VAX FMS. 


Explanation: You cannot access forms stored in VAX FMS 
libraries because you did not install FMS before you installed MMS 
on your system. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVOUTFIL, Using output file ’ filespec.’ 
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Explanation: MMS is writing all action lines and their resulting 
output to the specified output file. Note that messages preceded by 
"%MMS'" are not written into this file, but to SYS$ERROR. 


User Action: None. This is an informational message. It appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVPARSERR, Parser error: ‘message’ in file ‘filename,’ line ‘number.’ 


Explanation: The MMS parser failed, for the reason explained in 
the message text. 


User Action: Correct the erroneous action line in the description 
file. 


DRVQUALIF, Using non-defaulted qualifiers ‘qualifier name.’ 


Explanation: MMS is processing your description file using the 
specified qualifiers. These qualifiers, which are not enabled by 
default, correspond to the value of the $(MMSQUALIFIERS) 


reserved macro. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVRULFIL, Using rules file ’ filespec.’ 


Explanation: MMS is reading its default rules from the specified 
rules file. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


DRVSUBCLI, Using ‘CLI name’ for the subprocess CLI. 


Explanation: MMS is using the specified CLI to execute the 
subprocess. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


EXEBADREAD, Could not read command output from subprocess. 


Explanation: The MMS main process was unable to read the 
results of the action lines executed by the subprocess. 


User Action: This message indicates a problem with your system, 
possibly resulting from insufficient quotas or a mailbox problem. 
Check with your system manager. 


EXEBADWRT, Could not write command line to subprocess. 


Explanation: The MMS main process was unable to send an 
action line to the subprocess for execution. 


User Action: This message indicates a problem with your system, 
possibly resulting from insufficient quotas or a mailbox problem. 
Check with your system manager. 
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EXECANTWAKE, Could not wake up main process. 


Explanation: After executing an action line, the subprocess was 
unable to wake up the main process. 


User Action: This message indicates a problem with your system, 
possibly resulting from insufficient quotas or a mailbox problem. 
Check with your system manager. 


EXEDELPROC, Subprocess terminated abnormally. 


Explanation: The subprocess terminated unexpectedly, possibly 
because you used illegal commands like STOP or LOGOUT in your 
description file or because the subprocess was stopped by another 
process. 


User Action: Remove any invalid commands from the description 
file. 


EXEDELSES, Cleanup of subprocess %X’ value’ failed. 


Explanation: The $DELPRC system service could not delete the 
subprocess that was executing action lines. 


User Action: Type the DCL command SHOW SYSTEM/SUB to 
determine whether the subprocess still exists. If it does, type the 
STOP command to delete it: STOP/ID=’ value.’ If the subprocess 
does not still exist and this message was preceded by the message 
%MMS-F-EXEDELPROC, the subprocess was probably deleted by 
a user command such as LOGOUT. If this is the case, remove the 
offending command from the description file. 


EXENCRE, Could not create subprocess for executing action lines. 


Explanation: MMS could not create the subprocess for executing 
action lines. 


User Action: Check your quotas, and raise them if necessary. This 
message could also indicate a system problem. Check with your 
system manager. 


EXENEF, Unable to allocate event flag. 


Explanation: MMS was unable to allocate an event flag that 
allows the MMS main process to communicate with the subprocess. 


User Action: This message indicates a system problem. Check 
with your system manager. 
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EXENOAST, Could not enable AST. 


Explanation: MMS could not enable an AST that allows the main 
MMS process to send input to the subprocess and the subprocess to 
send output back to the main process. 


User Action: This message indicates a system problem. Check 
with your system manager. 


EXENOMBX, Unable to create mailbox for communicating with 
subprocess. 


Explanation: MMS could not create a mailbox for the MMS main 
process to use in communicating with the subprocess. 


User Action: This message indicates a problem with your process’s 
creation of mailboxes. Check with your system manager. 


EXEPROCID, PID of created subprocess is %X’ value.’ 


Explanation: The process ID of your subprocess is the value 
specified in the message. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


EXESTRING, Quoted string must be under ‘value’ characters. 


Explanation: A quoted string in an action line exceeded the 
maximum length allowed. 


User Action: Correct the action line in the description file. 


EXETOOBIG, Command too large. Maximum length is ‘value’ characters. 


Explanation: The command on an action line exceeded the maxi- 
mum command length allowed. 


User Action: Correct the command in the description file. 


FMSNOSUPP, DEC/MMS is installed without VAX FMS support. 


Explanation: Your description file specifies a form in an FMS 
library but you installed MMS without FMS support. 


User Action: VAX FMS must already be installed on your system 
before you install MMS if you want access to FMS forms. 
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FMSNOWILD, Wild cards are not allowed for VAX FMS library access. 


Explanation: You cannot use a wildcard character in the specifica- 
tion of an FMS form. 


User Action: Correct the description file to specify the forms you 
want MMS to access. 


GFBTYPEMIX, Illegal single/double colon rule mix for ‘item’ in line 


‘number.’ 


Explanation: The item named was specified as a target in both a 
single colon and a double colon dependency rule. 


User Action: Choose the rule you want for the build and make the 
description file consistent with respect to this target. 


GMBADMOD, Missing left parenthesis in library specification ’ filespec.’ 


Explanation: A library specification is missing a left parenthesis. 


User Action: Insert the missing parenthesis. 


GMFUTURE, Time for ' filename’ is in the future: ‘time.’ 


Explanation: MMS is attempting to access a target whose creation 
date is later than the current time. This can occur when system 
clocks are not exactly synchronized. 


User Action: Adjust the date of the file and try again. If neces- 
sary, adjust the system clocks. 


GMLCKRTRY, File ’ filename’ is locked by another user; retrying... 


Explanation: MMS is unable to get the modification date/time 
for files that are open for exclusive access by another process 
(for example, an .OBJ file that is currently being generated by a 
compilation currently in progress). MMS attempts the retry for 
5 minutes. 


User Action: Unlock the file or wait for MMS to time out. 


GMRTRYEXC, File ‘filename’ is locked by another user; retry limit 
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exceeded. MMS will assume it is current. 


Explanation: MMS has attempted to access a locked file; after 
5 minutes, MMS assumes the file is current and continues process- 
ing. 


User Action: None. This is an informational message that appears 
once MMS has completed its 5-minute retry. 


GMTIMFND, Time for 'filespec’ is ’ time.’ 


Explanation: The specified time is the latest revision time MMS 
found for the specified file. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


GWKBEGWLE, Starting the build at target ‘target name.’ 


Explanation: MMS will start its build process by trying to update 
the specified target. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


GWKCANT, MMS cannot update target ‘target name.’ 


Explanation: MMS cannot update the specified target because 
neither the description file nor the built-in rules indicate how to 

do it. Because you instructed MMS to ignore severe errors (using 
either IGNORE or /IGNORE=FATAL), processing of the description 
file continues. 


User Action: Revise the description file. Either remove the depen- 
dency on the target or describe how to update the target. 


GWKCHGEXC, $(MMS$CHANGED_LIST) exceeds maximum VMS string 
length; setting it to NULL. 


Explanation: The string for the $MMS$CHANGED_LIST) macro 
has exceeded the maximum VMS string size of 64KB. MMS sets 
the macro to null. 


User Action: Reduce the number of sources for the target being 
updated. 


GWKCONECT, Target ‘target name’ found in circular dependency. 


Explanation: The specified targets are involved in a circular 
dependency; that is, a source depends on its target. This message 
is always issued after the GWKLOOP message, which indicates 
the target for which a circular dependency was detected in the 
description file. 


User Action: Revise the description file to remove circular 
dependencies. 
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GWKCURRNT, Target ‘target name’ is already up-to-date. 


Explanation: MMS has not updated the specified target because 
it is already up-to-date. 


User Action: None. This is an informational message. 


GWKEXESTS, Status of executed command is %X’ condition code.’ 


Explanation: MMS has executed a CLI command in an attempt 
to update a target. The resulting condition code of the command is 
displayed in this message, and MMS attempts to decode its text in 


the following message line. If the next message line is blank, MMS 
cannot decode the message. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


GWKHSHOVER, Internal Hashtable Overflow. 
Explanation: This is an MMS internal error. 


User Action: Collect as much information as possible and submit 
a Software Performance Report (SPR). 


GWKLOOP, Circular dependency detected at target ‘target name.’ 


Explanation: The specified target is indirectly its own source. 
That is, you are asking MMS to make a target from the target 
itself, which is not legal. The ensuing GWKCONECT messages 
specify all relevant targets involved in the circular dependency. 


User Action: Revise the description file to remove circular 
dependencies. 


GWKNEEDUPD, An update is required for target ‘name.’ 


Explanation: This message is issued when /CHECK_STATUS is 
specified. 


User Action: None. This is an informational message. 
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GWKNOACTS, Actions to update ‘target name’ are unknown. 


Explanation: MMS cannot determine what actions to take in 
updating the specified target. This message may indicate a problem 
with the .SUFFIXES list or with your user-defined rules. There 
may be no built-in rule or user-defined rule for MMS to use. The 
file types in the user-defined rule might not be in the .SUFFIXES 
list, or they might be in the wrong order. 


User Action: Revise the description file. Specify the actions 
needed to update the target. 


GWKNOPRN, There are no known sources for the current target ' target 
name.’ 


Explanation: MMS has found no sources for the current target. 


User Action: Create a source file that can update the target. 


GWKNOREV, Cannot update modification time for file ' filespec.’ 


Explanation: MMS is unable to modify the revision time of the 
specified file, as directed by the (REVISE_DATE qualifier on the 
command line, because an error occurred. A possible reason for the 
error is that the file’s protection prohibited write access. 


User Action: Correct the file protection so that write access is 
allowed. 


GWKOLDNOD, Target ‘target name’ is older than ‘source names.’ 


Explanation: The specified target is older than the specified 
sources, so MMS will update it. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


GWKSRCEXC, $(MMS$SOURCE_LIST) exceeds maximum VMS string 
length; setting it to NULL. 


Explanation: The string for the $MMS$SOURCE_LIST) macro 
has exceeded the maximum VMS string size of 64KB. MMS sets 
the macro to null. 


User Action: Reduce the number of sources for the target being 
updated. 
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GWKUPDONE, Completed update for target ‘target name.’ 
Explanation: MMS has updated the specified target. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


GWKUPDTIM, Updating modification time for file ’ filespec.’ 


Explanation: MMS is changing the revision time of the specified 
file, as directed by the /(REVISE_DATE qualifier. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier, in addition 
to /REVISE_DATE. 


GWKWILLEX, MMS will try executing action line to update target ’ target 
name.’ 


Explanation: MMS will execute the action line to update the 
current target for one of the following reasons: at least one source 
may be more recent than the target, or the target may have no 
sources. 


User Action: None. This is an informational message that appears 
only if you have invoked MMS with the /LOG qualifier. 


IDENT, DEC/MMS ‘version’ COPYRIGHT (C) ‘date’ DIGITAL 
EQUIPMENT CORPORATION 


Explanation: This message provides the version number and 
copyright date of the MMS image installed on your system. You 
should include this information with any Software Performance 
Reports (SPRs) that you submit about MMS. 


User Action: None. This is an informational message that ap- 
pears only if you have invoked MMS with the [IDENTIFICATION 
qualifier. 


INTERNERR, Internal MMS Error. Please Report Error #’ number.’ 
Explanation: An MMS internal component failed. 


User Action: Collect as much information as possible and submit 
a Software Performance Report (SPR). 
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LBRNOELEM, Illegal library element is specified in ‘ filespec.’ 


Explanation: You used incorrect syntax to specify a library 
module. 


User Action: Correct the module syntax in the description file. 


LEXFILELOOP, Included file ’filespec’ is already open. 


Explanation: An included file is itself included at some deeper 
level. If undetected, this situation would cause an infinite sequence 
of included files. 


User Action: Remove the second level of inclusion in the file. 


LEXIFERR, Encountered .ENDIF without matching .IFDEF. 


Explanation: MMS found an .ENDIF directive in your description 
file but no corresponding .IFDEF directive. 


User Action: Correct the description file to remove the .ENDIF 
directive or add the necessary .IFDEF. 


LEXILLNAME, Specified target name ‘target’ on line ‘number’ is illegal. 


Explanation: You used incorrect syntax to indicate the target on 
the specified line number of the description file. 


User Action: Correct the description file. 


LEXUNEXEND, Continuation character found at end of file. 


Explanation: MMS found a hyphen (—) or a backslash (\ ) contin- 
uation character at the end of the description file. 


User Action: Revise the description file. Delete the continuation 
character or add another line. 


LFSBADFP, Cannot find source for target ’ filespec.’ 


Explanation: MMS cannot process an invalid file specification. 
This error can occur if you specified an undefined logical name as 
the target. 


User Action: Correct the syntax of the file specification and invoke 
MMS again. 
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MBBADMODE, Unknown mode parameter ‘mode number.’ 
Explanation: An internal MMS component failed. 


User Action: Collect as much information as possible and submit 
a Software Performance Report (SPR). 


MBREDEFILL, Illegal attempt to redefine macro ‘macro name.’ 


Explanation: You attempted to redefine the specified macro in 
the description file. You cannot define the same macro twice in one 
description file. The attempt is ignored, and the original definition 
applies. 


User Action: If you want to redefine a macro, you must use the 
/MACRO qualifier on the MMS command line. 


NOACCESS, Unable to access file ’ file.’ 


Explanation: This message is followed by one or more messages 
describing why the file could not be accessed. 


User Action: Modify the file protection of the inaccessible file. 


NOLIBSPECDBL, Library module specifications not allowed as targets in 
double colon rules: ‘ filespec.’ 


Explanation: You used a library module specification as a target 
in a double colon dependency rule. 


User Action: Rewrite the dependency as a single colon dependency 
using the library module specification or use only the library file 
name in your double colon dependency rule. You can write the 
preferred single colon syntax by using library module specifications. 
For example: 


UTIL(MOD1) : MOD1.OBJ 
LIBR UTIL.LIB MOD1.OBJ 


UTIL(MOD2) : MOD2.OBJ 
LIBR UTIL.LIB MOD2.OBd 


The following dependency rule is correct for the double colon use: 


UTIL.OLB :: MOD1.OBJ 
LIBR UTIL.LIB MOD1.OBJ 


UTIL.OLB :: MOD2.OBJ 
LIBR UTIL.LIB MOD2.OBJ 
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NOMACFIL, Cannot open macro file ’ filespec.’ 


Explanation: You specified either an illegal or a nonexistent file 
in the command line macro definitions. 


User Action: Create the file, or correct the file specification. 


NOOUTFIL, Cannot open output file ’ filespec.’ 
Explanation: MMS failed to create the output file. 


User Action: Verify that the file specification is legal, check your 
disk quota, or check the protection of an existing file of the same 
name as the output file. 


NOSTATUS, Unable to set MMS$STATUS to ‘value.’ 


Explanation: MMS received an error from VMS when trying to 
set the symbol MMS$STATUS. This error may occur if you have 
exceeded the available space for symbols defined by your process, or 
if symbol scope is set to noglopal. 


User Action: Either remove some of your symbols or have the 
system manager change the SYSGEN parameter CLISYMTBL or 
set symbol scope to global. 


NOTARGET, No target specified. 
Explanation: You did not specify a target for MMS to build. 


User Action: Specify a target on the MMS command line, or 
correct the description file so that it specifies a target. 


UTLALLOCFAIL, Failed to allocate memory for dynamic data structures. 


Explanation: An MMS call to obtain more virtual memory failed. 
Either your description file is too large or a system service failed 
unexpectedly. 


User Action: Try trimming your description file. If this fails, 
consult your system manager about increasing the size of virtual 
address space available to your system processes. If this fails, 
submit a Software Performance Report (SPR). 
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UTLBADMAC, Unterminated macro name ‘ string.’ 


Explanation: The character combination $( was encountered 
without a matching closing parenthesis. As a result, on the line 
that contains the offending macro, all characters to the right of the 
$( are ignored. 


User Action: Correct the erroneous line. 


UTLUNDERFLOW, Deallocation of unallocated space. 
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Explanation: This is an internal MMS error. 


User Action: Collect as much information as possible and submit 
a Software Performance Report (SPR). 


Appendix B 
MMS and UNIX make Comparisons 


This appendix briefly compares the characteristics of MMS and the UNIX 
Version 7 make utility . It is designed to ease the transition to MMS for 
users already familiar with make. 


Because VMS and UNIX are very different operating systems, certain 
system-imposed changes were necessary to provide the features of make on 
VMS. The experienced user of make will notice the following differences: 


¢ In the absence of a (DESCRIPTION or /NODESCRIPTION qualifier, 
MMS looks first for the description file DESCRIP.MMS. It looks for 
MAKEFILE. only if it cannot locate DESCRIP.MMS. If it cannot find 
DESCRIP.MMS or MAKEFILE., it looks for target-name.MMS. 


e In the target or source line of a dependency rule, there must be at 
least one space or tab on either side of the colon or double colon that 
separates the list of targets from the list of sources. The space or tab 
prevents MMS from trying to interpret the colon or colons as part of a 
VMS file specification. 


¢ With MMS, you can use commas as well as spaces to separate the 
elements in a list of targets or sources. 


¢ You can use either a number sign (#) or an exclamation point (!) asa 
comment character. On target or source lines, as well as on blank lines 
that separate dependency rules, you can use the number sign and the 
exclamation point interchangeably; however, on action lines, you can use 
only the exclamation point to indicate a comment. 


¢ In MMS, subprocesses are not executed independently of one another. 
Therefore, it is possible to define logical names, change directories, and 
in general manipulate the subprocess environment at will. 


¢ The dummy target .PRECIOUS, found in make, is not implemented 
in MMS. 
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e When invoking a macro in MMS, you must enclose the macro name in 
parentheses. That is, $(A) is a legal invocation of an MMS macro, but 
$A is not. 


¢ MMS action lines may begin with either a space or a tab. MMS assumes 
that any line that begins with a space or tab is an action line unless the 
preceding line ends with a continuation character. 

¢ MMS has different built—in rules from those of make. See Table C-6 for 
the format and contents of MMS built-in rules. 

¢ MMS requires you to separate the Silent (@) and Ignore (-) action line 
prefixes from the rest of the action line by at least one space. 


e In a description file, the line continuation character can be either a 
hyphen (-) or a backslash (\ ). On the MMS command line, only the 
hyphen is legal. 


¢ In the specification of a VMS library module, you can use the question 
mark (?) wildcard character as a synonym for the percent sign (%) 
wildcard character. 


¢ MMS has an optional format for dependency rules: 
PROG.OBJ DEPENDS ON PROG.C 
UTIL.LIB ADDITIONALLY DEPENDS _ON MOD1.0BJ 


In this format, you can use DEPENDS_ON in place of the colon, and 
ADDITIONALLY_DEPENDS_ON in place of the double colon. 


For compatibility with make, MMS provides alternative formats for 
dependency rules, user-defined rules, and directives, and recognizes 
2~—character abbreviations for special macros. The experienced user of make 
will recognize the following make features in MMS: 


MMS allows the following alternative format for dependency rules: 
target... {source ... ] ; [action line... ] 


In this format, the only legal comment character is an exclamation point 
(!). You cannot use the Ignore (-) action line prefix with this format 
because the hyphen is interpreted as a line continuation character. 


¢ MMS allows the following alternative format for user-defined rules: 
-SRC.TAR : ; action line. 


In this format, you must include at least one space or tab on each side 
of the colon and the semicolon to prevent MMS from trying to interpret 
the rule as a file specification. You cannot use the Ignore (-) action 
line prefix with this format because the hyphen is interpreted as a line 
continuation character. 


B-2 MMS and UNIX make Comparisons 


You can place a colon after the name of a directive. For example, you 
can specify either SILENT or .SILENT : in a description file. 


The period preceding the .INCLUDE directive is optional. 


You can abbreviate MMS special macros to two characters (see 
Table C-—3). 
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Appendix C 
MMS Built-In Features 


This appendix contains tables of MMS built-in features, including the 
default macros, the suffixes precedence list, and the built-in rules. 
Chapter 2 contains detailed information about how these three features 
work together in MMS. 


The tables in this appendix are arranged as follows: 


¢ Table C~—1 lists the default macros. 


¢ Table C—2 lists the changed default macros when you use the /SCA_ 
LIBRARY qualifier. 


e Table C-3 lists the special macros. 

¢ Table C—4 contains the suffixes precedence list. 

¢ Table C-5 lists and describes the directives used in a description file. 
¢ Table C-6 contains the standard built-in rules. 

Section C.7 describes the built-in rules for accessing VMS libraries. 
Section C.8 lists the built-in rules that change when you use the /SCA_ 


LIBRARY qualifier. Section C.9 includes the built-in rules for accessing 
CMS library elements. 


For information on using MMS to create and access elements in VMS 
libraries, see Section 4.1; in CMS libraries, see Section 4.2. 
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C.1 Default Macros 


MMS uses the default macros, shown in Table C—1, to build your system if 


none are specified or redefined. 


Table C—1: MMS Default Macros 


Macro Definition 
ANLFLAGS /OUTPUT=$(MMS$TARGET_NAME).ANL 
AS MACRO 
BASFLAGS! /NOLIST/OBJ ECT=$(MMS$TARGET_NAME).OBJ 
BASIC BASIC 
BFLAGS? /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
BLIBFLAGS! /NOLIST 
BLISS BLISS 
- BLISS16 BLISS/PDP11 
CC CC 
CDDFLAGS null string 
CFLAGS? /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
CLDFLAGS null string 
CMS CMS 
CMSCOMMENT null string 
CMSFLAGS /GEN=$(MMS$CMS_GEN) 
COBFLAGS! /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
COBOL COBOL 
CORAL CORAL 
CORFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
DBLFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
DIBOL DIBOL 
FFLAGS’ /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
FMS FMS 
FMSFLAGS /REPLACE 


1This default macro changes when you use the /SCA_LIBRARY qualifier. (See Table C-2.) 


(continued on next page) 
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Table C—1 (Cont.): 


Macro 


FORMS 


FORMS_EXOBJ_ 
FLAGS 


FORMS_TRANS_ 
FLAGS 


FORT 
LIBR 
LIBRFLAGS 
LINK 
LINKFLAGS 


-. MACRO 


- MFLAGS! 

-MSGFLAGS 
PASCAL 
PENVFLAGS 
PFLAGS! 

PLI 
PLIFLAGS! 
RALFLAGS 
RALLY 
RFLAGS 
RPG 
RPGFLAGS 
RUNOFF 
SCA 
SCAFLAGS 
SCALIBRARY! 
SCAN 
SCANFLAGS! 


MMS Default Macros 


Definition 


FORMS 
/NOLIST/OUTPUT=$(MMS$TARGET_NAME).OBJ 


IN OLIST/OUTPUT=$(MMS$TARGET_NAME).FORM 


FORTRAN 
LIBRARY 

/REPLACE 

LINK © 
/TRACE/NOMAP/EXEC=$(MMS$TARGET_ NAME). EXE 
MACRO 
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
PASCAL 

/NOLIST 
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
PLI ar 
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 
null string 

RALLY 

/OUTPUT-§(MMS$TARGET_NAME).OBJ 

RPG 

INOLIST/IOBJECT-8(MMS$TARGET _ NAME).OBJ 
RUNOFF 

SCA 

/LOG 

Not defined 

SCAN ; 
/NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ 


1This default macro changes when you use the /SCA_LIBRARY qualifier. (See Table C-2.) 
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C.2 Default Macro Changes with the /SCA_LIBRARY 
Qualifiers 


Table C-—2 lists the default macro changes with the /SCA_LIBRARY 
qualifier. 


Table C—2: The /SCA_LIBRARY Qualifiers Default Macros 


Macro Definition 

SCA SCA 

SCALIBRARY Library name from the /SCA_LIBRARY qualifier 

BASFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

BFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

BLIBFLAGS /NOLIST/ANALYSIS_DATA=$(MMS$TARGET_NAME).ANA 

CFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

COBFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

FFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

MFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

PFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 

PLIFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 


DATA=$(MMS$TARGET_NAME).ANA 


SCANFLAGS /NOLIST/OBJECT=$(MMS$TARGET_NAME).OBJ/ANALYSIS_ 
DATA=$(MMS$TARGET_NAME).ANA 


C.3 Special Macros 


Table C—3 lists the MMS special macros and describes their functions. The 
table also lists a symbol that you can use as an abbreviation for each macro. 
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Table C-3: MMS Special Macros 


Macro Symbol Meaning 


MMS$TARGET $@ Expands to the mnemonic name or the 
complete file specification of the target 
currently being updated. 

MMS$TARGET_NAME $* Expands to the mnemonic name or the file 
name (excluding the file type) of the target 
being updated. The device, directory, and 
node information are included. 

MMS$SOURCE $< Expands to the source file specification. 


MMS$SOURCE_LIST $+ Expands to a comma list of the full file 
specifications of all sources specified 
in this dependency rule, including any 
sources implied by built-in rules. 

MMS$CHANGED_ LIST $? Expands to a comma list of the full file 
specifications of all sources that have 
changed since the target was updated, 
including any sources implied by built-in 
rules. 

MMS$LIB_ELEMENT $% Expands to the name of a module in a 
VMS library and its file name, including 
the file type (see Section 4.1). 

MMS$CMS_ELEMENT $< Expands to the implicit CMS element 
specification (if the source file is a CMS 
element). 

MMS$CMS_GEN $& Expands to the CMS generation specified 
by the source file (Gif the source is a CMS 

element). 

MMS$CMS_LIBRARY $@ Expands to the CMS library specification 

(if the source is a CMS element). 
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C.4 Suffixes Precedence List 


Table C-4 provides the MMS suffixes precedence list. 


Table C-4: Suffixes Precedence List 


SSUFFIXES 


-ANL .EXE .OLB .MLB .HLB .TLB .FLB .OBJ .FORM 
.BLI .B32 .C .COB .FOR .BAS .B16 .PLI .PEN .PAS 
-MAC .MAR .CLD .MSG .COR .DBL .RPG .SCN .IFDL 
-RBA .RC .RCO .RFO .RPA .SC .SCO .SFO .SPA .SPL 
.SQLMOD .RGK .RGC .MEM .RNO .HLP .RNH .L32 
.REQ .R32 .L16 .R16 .TXT .H .FRM .MMS .DDL .COM 
.DAT .OPT .CDO .SDML .ADF .GDF .LDF .MDF .RDF 
.TDF .ADF~' .ANL~ .B16~ .B32~ .BAS~ .BLI~ .C~ 
.CDO~ .CLD~ .COB~ .COM~ .COR~ .DAT~ .DBL~ 
.DDL~ .FOR~ .FRM~ .GDF~ .HLP~ .H~ .IFDL~ .LDF~ 
.MAC~ .MAR~ .MDF~ .MMS~ .MSG~ .OPT~ .PAS~ 
.PLI~ .R16~ .R32~ .RBA~ .RC~ .RCO~ .RDF~ .REQ~ 
-RFO~ .RGC~ .RNH~ .RNO~ .RPA~ .RPG~ .SC~ .SSCN~ 
SCO~ .SSDML~ .SFO~ .SPA~ SPL~ SQLMOD~ .TDF~ 
.TXT~ 


1A tilde (~) after a file type indicates that the file is in a CMS library. See Section 4.2 for 
information on using MMS to access CMS elements. 


C.5 Directives 


Table C—5 lists and describes all the MMS directives. 


Table C—5: MMS Directives 


Directive 


.DEFAULT 


.ELSE 
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Function 


Indicates actions to be performed if MMS built-in rules 
or user—defined rules do not specify how to update a 
target. 


Causes subsequent lines of a description file to be 
processed if the specified macro for the .IFDEF directive 
is undefined. 


(continued on next page) 


Table C—5 (Cont.): 


Directive 


ENDIF 
FIRST 
.FDEF 
IGNORE 


INCLUDE 
.LAST 


SILENT 


SUFFIXES 
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MMS Directives 
Function 


Terminates the set of lines in the description file whose 
processing is controlled by .IFDEF or .ELSE. 


Indicates actions to be performed before MMS has 
executed any action lines to update the target. 


Causes subsequent lines of a description file to be 
processed only if the specified macro is defined. 


Causes MMS to ignore all errors generated by all action 
lines and to continue processing the description file. 


Includes the specified file in the description file. 


Indicates actions to be performed after MMS has exe- 
cuted all the action lines that update the target. 


Suppresses the writing of all action lines to the output 
file (whether to SYS$OUTPUT or to the file specified by 
the /OUTPUT qualifier). 


Clears, adds to, or redefines the suffixes precedence list. 


Table C-6 lists the sources, targets, and actions for the MMS built-in rules. 


Table C-—6: MMS Built-In Rules 


Source Target 
.B16} OBJ 
.B32 .OBJ 
.BAS! .OBJ 
BLE! .OBJ 
Cc} OBJ 
.CLD OBS 


Action 


$(BLISS16) $(BFLAGS) $(MMS$SOURCE) 

$(BLISS) $(BFLAGS) $(MMS$SOURCE) 

$(BASIC) $(BASFLAGS) $(MMS$SOURCE) 

$(BLISS) $(BFLAGS) $(MMS$SOURCE) 

$(CC) $(CFLAGS) $(MMS$SOURCE) 

SET COMMAND /OBJECT=$(MMS$TARGET_NAME) 


1The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8 


for a list of rules changes. 


(continued on next page) 
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Table C—6 (Cont.): MMS Built-In Rules 


Source Target Action 
$(CLDFLAGS) $(MMS$SOURCE) 

.COB? OBJ $(COBOL) $(COBFLAGS) $(MMS$SOURCE) 

.COR .OBJ $(CORAL) $(CORFLAGS) $(MMS$SOURCE) 

.DBL OBJ $(DIBOL) $(DBLFLAGS) $(MMS$SOURCE) 

EXE NL ANALYZE/IMAGE $(ANLFLAGS) $(MMS$SOURCE) 

.FOR} OBJ $(FORT) $(FFLAGS) $(MMS$SOURCE) 

.FORM OBJ $(FORMS) EXTRACT OBJECT $(FORMS_EXOBJ_FLAGS) 
$(MMS$SOURCE) 

IFDL .FORM $(FORMS) TRANSLATE $(FORMS_TRANS_FLAGS) 
$(MMS$SOURCE) 

MAC OBJ $(MACRO) $(MFLAGS) $(MMS$SOURCE) 

MAR} OBJ $(MACRO) $(MFLAGS) $(MMS$SOURCE) 

.MSG OBJ MESSAGE $(MSGFLAGS) $(MMS$SOURCE) 

OBJ ANL ANALYZE/OBJECT $(ANLFLAGS) $(MMS$SOURCE) 

.OBJ .EXE $(LINK) $(LINKFLAGS) $(MMS$SOURCE) 

PAS! OBJ $(PASCAL) $(PFLAGS) $(MMS$SOURCE) 

.PAS .PEN $(PASCAL) /ENVIRON=$(MMS$TARGET) 
$(PENVFLAGS) $(MMS$SOURCE) 

PL}? OBJ $(PLI) $(PLIFLAGS) $(MMS$SOURCE) 

R16} .L16 $(BLISS16) /LIBRARY=$(MMS$TARGET) 

.R32! .L32 $(BLISS) /LIBRARY=$(MMS$TARGET) 

.REQ? .L32 $(BLISS) /LIBRARY=$(MMS$TARGET) 

.RGC .RGK $(RALLY) DEFINE KEYS $(RALFLAGS) $(MMS$SOURCE) 
$(MMS$TARGET) 

.RNH -HLP $(RUNOFF) $(RFLAGS) $(MMS$SOURCE) 

.RNO MEM $(RUNOFF) $(RFLAGS) $(MMS$SOURCE) 
$(BLIBFLAGS) $(MMS$SOURCE) 

RPG OBJ $(RPG) $(RPGFLAGS) $(MMS$SOURCE) 


$(BFLAGS) $(MMS$SOURCE) 


1The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8 
for a list of rules changes. 


(continued on next page) 
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Table C-6 (Cont.): MMS Built-In Rules 


Source Target Action 
$(BFLAGS) $(MMS$SOURCE) 
SCN? .OBJ $(SCAN) $(SCANFLAGS) $(MMS$SOURCE) 


1The use of the /SCA_LIBRARY qualifier changes some of these built-in rules. See Section C.8 
for a list of rules changes. 


C.7 Built-In Rules for Library Files 


The following example shows how to build a help library: 


-HLP.HLB 
IF "'! FSSEARCH ("$ (MMSSTARGET)")’" .EQS. "" - 
THEN $ (LIBR) /CREATE/HELP $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $ (MMS$SOURCE) 


The following example shows how to build a macro library: 


.MAR.MLB 
IF "!’FSSEARCH ("S$ (MMS$STARGET)")'" .EQS. "" - 
THEN $ (LIBR) /CREATE/MAC $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $ (MMSSSOURCE) 


-MAC.MLB 
IF "’’FSSEARCH ("S$ (MMS$TARGET)")/" .EQS. "" - 
THEN $ (LIBR) /CREATE/MAC $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) $(MMSSTARGET) $ (MMSS$SOURCE) 


The following example shows how to build an object library: 


.OBJ.OLB 
IF "’'FSSEARCH("$(MMSS$TARGET)")'" .EQS. "" - 
THEN $(LIBR)/CREATE $ (MMSS$TARGET) 
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE) 


- TXT. TLB 
IF "’’FSSEARCH ("S$ (MMSSTARGET)")’" .EQS. "" - 
THEN $ (LIBR) /CREATE/TEXT $ (MMSSTARGET) 
$(LIBR) $(LIBRFLAGS) $(MMS$TARGET) $ (MMSSSOURCE) 


The following example shows how to build a FMS library: 


-FRM.FLB 
IF "’’FSSEARCH ("S$ (MMSSTARGET)")'" .NES. "" = 
THEN $(FMS) /LIBRARY $(FMSFLAGS) $(MMSSTARGET) $ (MMS$SOURCE) 
IF "’/FSSEARCH("S$(MMSSTARGET)")'’" .EQS. "" - 
THEN $ (FMS) /LIBRARY/CREATE $(MMSSTARGET) $(MMSS$SOURCE) 
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C.8 Built-In Rules for the /SCA_LIBRARY Qualifier 


This section lists the changes to built-in rules when you use the /SCA_ 
LIBRARY qualifier. 


-BAS.OBJd : 
$(BASIC) $(BASFLAGS) $ (MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN- 
mms$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND.- 
mms$scalib .NES. "$(SCALIBRARY)" THEN mmsSscasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mmsSscasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsSscasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mmsS$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
S$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsSscasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ’mmsS$scalib’ 


.BLI.OBJ : 
$(BLISS) $(BFLAGS) $ (MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mmsSscasetlib = 0 


IF mmsS$scalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN ~ 
mmsS$scasetlib = 2 

IF mms$scalib .NES. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "S$(SCALIBRARY)" THEN mmsS$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ’mmsS$scalib’ 


-B32.OBJ : 
$(BLISS) $(BFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mms$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mmsSscasetlib = (mmsS$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsS$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY ) 

IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ’mmsS$scalib’ 


C-10 MMS Built-In Features 


.C.OBJ : 
$(CC) $(CFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "“SCASLIBRARY" ) 
mmsSscasetlib = 0 


IF mmsSscalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mmsS$scalib .NES. "S(SCALIBRARY)" THEN mmsSscasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsSscasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) 
$ (SCALIBRARY ) 

IF (mmsSscasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $ (SCAFLAGS) 
$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ‘mmsS$scalib’ 


~COB.OBJ : 
$ (COBOL) $(COBFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mmsS$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsS$scalib .NES. "" .AND. "$(SCALIBRARY)" .NES. “SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mms$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 

IF ((mmsS$scasetlib .AND. 4) .EQ. 4) THEN SPAWN/WAIT/NOSYMBOLS $(SCA) - 
CREATE LIBRARY $(SCAFLAGS) $ (SCALIBRARY) 

IF ((mms$scasetlib .AND. 4) .EQ. 4) .OR. ((mms$scasetlib .AND. 2) .EQ. 2) - 
THEN DEFINE/USER SCASLIBRARY $ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSS$TARGET_NAME) .ANA 


-FOR.OBJ : 
S$ (FORT) S(FFLAGS) $ (MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
Ims$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "S$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mmsSscalib .NES. "S$(SCALIBRARY)" THEN mmsSscasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY ) 

IF (mmsSscasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $(MMSSTARGET NAME) .ANA 

IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ‘'mmsS$scalib’ 
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-MAR.OBJ : 
$ (MACRO) $(MFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mmsSscasetlib = 2 

IF mms$scalib .NES. "" .AND. "$(SCALIBRARY)" .NES. “SCASLIBRARY:" .AND. - 
mms$scalib .NES. "S(SCALIBRARY)" THEN mms$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mmsS$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsSscasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mmsS$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY ) 

$(SCA) LOAD $(SCAFLAGS) $(MMS$TARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) 'mms$scalib’ 


-PAS.OBJ : 
$(PASCAL) $(PFLAGS) $ (MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mmsSscasetlib = 0 


IF mmsSscalib .EQS. "" .AND. "S(SCALIBRARY)" .NES. "“SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsS$scalib .NES. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mmsS$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mmsS$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsS$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mmsSscasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

$(SCA) LOAD S$ (SCAFLAGS) $ (MMSSTARGET_ NAME) .ANA 

IF mmsSscasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ‘mms$scalib’ 


»~PLI.OBJ : 
$(PLI) $(PLIFLAGS) $ (MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mmsSscalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mms$scalib .NES. "" .AND. "S(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "S(SCALIBRARY)" THEN mms$scasetlib = 3 

IF FSSEARCH("S (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mmsSscasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsSscasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mmsSscasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY ) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ’mms$scalib’ 
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-REQ.L32 : 
$ (BLISS) /LIBRARY=$ (MMSSTARGET) $(BLIBFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mmsSscalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "S$(SCALIBRARY)" .NES. "“SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mmsS$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mms$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mmsS$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY ) 

$(SCA) LOAD $(SCAFLAGS) $(MMSSTARGET_NAME) .ANA 

IF mms$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ‘mmsS$scalib’ 


~-R32.L32 : 
$ (BLISS) /LIBRARY=$ (MMSSTARGET) $(BLIBFLAGS) $(MMSSSOURCE) 
mms$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mms$scalib .EQS. "" .AND. "$(SCALIBRARY)" .NES. "“SCASLIBRARY:" THEN - 
mms$scasetlib = 2 

IF mmsSscalib .NES. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mms$scasetlib = 3 

IF FSSEARCH ("$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 


mms$scasetlib = (mmsS$scasetlib .AND. .NOT. 2) .OR. 4 

IF (mms$scasetlib .AND. 4) .EQ. 4 THEN $(SCA) CREATE LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) : 

IF (mms$scasetlib .AND. 2) .EQ. 2 THEN $(SCA) SET LIBRARY $(SCAFLAGS) - 
$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $ (MMSSTARGET_NAME) .ANA 

IF mmsS$scasetlib THEN $(SCA) SET LIBRARY $(SCAFLAGS) ‘mmsSscalib’ 


.SCN.OBJ : 
$(SCAN) $(SCANFLAGS) $ (MMSSSOURCE) 
mmsS$scalib = FSTRNLNM( "SCASLIBRARY" ) 
mms$scasetlib = 0 


IF mmsS$scalib .EQS. "" .AND. "S(SCALIBRARY)" .NES. "“SCASLIBRARY:" THEN - 
mmsS$scasetlib = 2 

IF mms$scalib .NES. "" .AND. "$(SCALIBRARY)" .NES. "SCASLIBRARY:" .AND. - 
mms$scalib .NES. "$(SCALIBRARY)" THEN mmsS$scasetlib = 3 

IF FSSEARCH ("S$ (SCALIBRARY) SCASEVENT.DAT") .EQS. "" THEN - 
mms$scasetlib = (mmsS$scasetlib .AND. .NOT. 2) .OR. 4 


IF ((mmsSscasetlib .AND. 4) .EQ. 4) THEN SPAWN/WAIT/NOSYMBOLS $(SCA) - 
CREATE LIBRARY $(SCAFLAGS) $(SCALIBRARY) 

IF ((mms$scasetlib .AND. 4) .EQ. 4) .OR. ((mms$scasetlib .AND. 2) .EQ. 2) - 

THEN DEFINE/USER SCASLIBRARY S$ (SCALIBRARY) 

$(SCA) LOAD $(SCAFLAGS) $(MMSS$TARGET_NAME) .ANA 
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C.9 Built-In Rules for CMS Access 


This section lists the built-in rules for CMS access. A tilde (~) after a file 
type indicates that the file is in a CMS library. 


-ANL~.ANL : 
IF mms$cmslib .nes. "S$ (MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_ NAME) .ANL - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-ADF~.ADF 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSS$CMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .ADF - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-B16~.B16 
IF mms$cmslib .nes. "$(MMSS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMS$CMS_LIBRARY) 
$ (CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME).B16 - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.B32~.B32 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .B32 - 
$(CMSFLAGS) $(CMSCOMMENT) 


. BAS~. BAS 
IF mms$cmslib .nes. "$(MMSS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME).BAS - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-BLI~.BLI 
IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSS$CMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .BLI - 
$(CMSFLAGS) $ (CMSCOMMENT) 


C~.C 
IF mms$cmslib .nes. "S$ (MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$(MMSS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME).C - 
$(CMSFLAGS) $(CMSCOMMENT) 
-CLD~.CLD : 
IF mms$cmslib .nes. "$(MMS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$(MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME).CLD - 
$(CMSFLAGS) $ (CMSCOMMENT) 
. COB~. COB 


IF mms$cmslib .nes. "$(MMSS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .COB - 
$(CMSFLAGS) $ (CMSCOMMENT) 
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-COR~.COR : 


IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .COR - 
$(CMSFLAGS) $ (CMSCOMMENT) 


»COM~.COM : 


IF mms$cmslib .nes. "$(MMSSCMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .COM - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-DAT~.DAT : 


IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .DAT - 
$(CMSFLAGS) $(CMSCOMMENT) 


-DBL~.DBL : 


IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .DBL - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-DDL~.DDL : 


IF mms$cmslib .nes. "S$ (MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .DDL - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-FOR~.FOR : 


IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .FOR - 
$(CMSFLAGS) $(CMSCOMMENT) 


-ERM~.FRM : 


IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .FRM - 
$(CMSFLAGS) $(CMSCOMMENT) 


-GDF~.GDF 


IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMS$CMS_LIBRARY) 

$(CMS) FETCH $(MMSS$CMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .GDF - 
$(CMSFLAGS) $ (CMSCOMMENT) 


IF mms$cmslib .nes. "$(MMSSCMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_ LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .H - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-HLP~.HLP 


IF mms$cmslib .nes. "$(MMS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_ LIBRARY) 

$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .HLP - 
$(CMSFLAGS) $ (CMSCOMMENT) 
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-IFDL~.IFDL : 
IF "$(MMS$CMS_ LIBRARY)" .NES. "" THEN DEFINE/USER CMS$LIB - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).IFDL - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.LDF~.LDF : 
IF mms$cmslib .nes. "$(MMSS$SCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).LDF - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-MAC~.MAC : 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .MAC - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-MAR~.MAR : 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 
$ (CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMSS$TARGET_NAME) .MAR - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-MDF~.MDF : 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSS$TARGET_NAME) .MDF - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-MMS~.MMS : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMSS$CMS_LIBRARY) 
$ (CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .MMS - 
S(CMSFLAGS) $ (CMSCOMMENT) 


-MSG~.MSG : 
IF mms$cmslib .nes. "$(MMS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .MSG - 
S(CMSFLAGS) $ (CMSCOMMENT) 


-OPT~.OPT ; 
IF mmsS$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=S (MMS$TARGET_NAME) .OPT - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.PAS~.PAS : 
IF mms$cmslib .nes. "S$ (MMSS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSS$CMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .PAS - 
S(CMSFLAGS) $(CMSCOMMENT) 


.PLI~.PLI : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMSS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMSS$TARGET_NAME) .PLI - 
$(CMSFLAGS) $ (CMSCOMMENT) 
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»~R16~.R16 : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .R16 - 
S(CMSFLAGS) $ (CMSCOMMENT) 


.R32~.R32 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .R32 - 
S(CMSFLAGS) $ (CMSCOMMENT) 


-RBA~.RBA : 
IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSS$CMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME).RBA - 
$(CMSFLAGS) $ (CMSCOMMENT) 


»~-RC~.RC : 
IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_ LIBRARY) 
$(CMS) FETCH $(MMSS$SCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).RC - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-RCO~.RCO : 
IF mms$cmslib .nes. "$(MMSS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).RCO - 
$(CMSFLAGS) $(CMSCOMMENT) 


.REQ~.REQ : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMS$TARGET NAME) .REQ - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.RFO~.RFO : 
IF mmsScmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME).RFO - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-RGC~.RGC 
IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .RGC - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-RNH~.RNH : 

IF mmsScmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) 

$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .RNH - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-RNO~.RNO : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY ~ 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).RNO - 
S(CMSFLAGS) $ (CMSCOMMENT) 
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-RPA~.RPA : 
IF mms$cmslib .nes. "$(MMSS$CMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .RPA - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.RPG~.RPG : 
IF mms$cmslib .nes. "$(MMSSCMS LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS ELEMENT) /OUTPUT=$ (MMSSTARGET NAME) .RPG - 
$(CMSFLAGS) $ (CMSCOMMENT) 


~SC~.SC : 
IF mmsScmslib .nes. "S (MMSSCMS_LIBRARY) " THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $ (MMS$CMS_ELEMENT) /OUTPUT=S (MMSSTARGET_NAME) .SC - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.SCN~.SCN : 
IF mms$cmslib .nes. "S(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$ (MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .SCN - 
$(CMSFLAGS) $ (CMSCOMMENT) 


-SCO~.SCO : 
IF mms$cmslib .nes. "$(MMS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMSS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .SCO - 
$(CMSFLAGS) $ (CMSCOMMENT) 


SPO. SFO: 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSS$CMS_ELEMENT) /OUTPUT=$ (MMS$TARGET_ NAME) .SFO - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.SDML~.SDML : 
IF mms$cmslib .nes. "$(MMSS$CMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMSSCMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS_ ELEMENT) /OUTPUT=$ (MMS$TARGET NAME) .SDML - 
$(CMSFLAGS) $ (CMSCOMMENT) 


.SPA~.SPA : 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMSSCMS ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME).SPA - 
$(CMSFLAGS) $(CMSCOMMENT) 


-SPL~.SPL : 
IF mms$cmslib .nes. "$(MMS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .SPL - 
$(CMSFLAGS) $ (CMSCOMMENT) 


- SQLMOD~.SQLMOD : 
IF mms$cmslib .nes. "$(MMSSCMS_ LIBRARY)" THEN $(CMS) SET LIBRARY 
$(MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS_ ELEMENT) /OUTPUT=$ (MMS$TARGET_NAME) .SQLMOD - 
$(CMSFLAGS) $ (CMSCOMMENT) 
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.TDF~,. TDF 
IF mms$cmslib .nes. "$(MMSSCMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMS$CMS_LIBRARY) 
$(CMS) FETCH $(MMS$CMS ELEMENT) /OUTPUT=$ (MMSSTARGET_NAME) .TDF - 
$(CMSFLAGS) $(CMSCOMMENT) 


~TXT~.TXT 
IF mms$cmslib .nes. "S$ (MMSS$CMS_LIBRARY)" THEN $(CMS) SET LIBRARY - 
$ (MMSSCMS_LIBRARY) q 
$(CMS) FETCH $(MMS$CMS_ELEMENT) /OUTPUT=S (MMSSTARGET_ NAME) .TXT - 
$(CMSFLAGS) $ (CMSCOMMENT) 
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Glossary 


action 


A command-language command that MMS executes to update a target. 
(See also action line.) 


action line 


The part of the dependency rule that contains the commands that tell 
MMS how to use the source or sources to update the target. (See also 
dependency rule.) 


action line prefix 
A special character placed at the beginning of an action line that 
influences how MMS executes the action. (See also action line.) 


built-in rule 


A command that MMS uses when the description file does not explicitly 
describe the processing needed to update a target. 


default macro 
A name that represents a character string that defines commonly used 
operations. MMS built-in rules are expressed in terms of default macros. 
(See also built-in rule and macro.) 


dependency rule 
The description of a relationship between a target and one or more 
sources, and the action or actions required to update the target. 
Dependency rules are contained in the description file. (See also 
description file.) 
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description file 


A text file that contains the dependency rules, comments, macros, and 
directives that MMS uses to build your system. (See also dependency 
rule, directive, and macro.) 


directive 
A word that specifies an action for the processing of the description file. 


included file 


A shared file used during software development that contains code or 
constant declarations. 


library module specification 
A VMS file specification for a module in a library. 


macro 


A name that represents a character string. The string is substituted for 
the name in a dependency rule. 


macro invocation 


The execution of the macro that replaces the macro name with its 
definition. 


mnemonic name 


A name that identifies the purpose of a sequence of related actions. It 
can be used as either a source or a target in the description file. (See 
also source and target.) 


object library 
A single file that contains multiple object files. (See also object module.) 


object module 
One or more object files that comprise an object library. 


source 
In a dependency rule, an entity that is used to create or to update the 
target. A source can be a VMS file specification or a mnemonic name. 
(See also dependency rule and mnemonic name.) 


special macro 


A name that represents a character string that expands to source or 
target names in the dependency currently being processed. A special 
macro is used instead of a target or source file specification when writing 
general user-defined rules. (See also dependency rule, macro, and 
target.) 


suffixes precedence list 


A list of file types to which MMS refers when it needs to know which 
source file can update the specified target. 


target 


In a description file, the entity that is to be updated. A target can be a 
VMS file specification or a mnemonic name. (See also mnemonic name.) 


user-defined rule 


A rule that the user specifies in the description file to add to and/or 
replace MMS built-in rules. (See also built-in rule.) 
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index 





A 


Action line, 2-3, 2-22 
command procedures, 2-28 
comments, 2-24 
definition of, 1-4 
effect of /ACTION on, CD-4 
errors, 2-29 
example, 2-22 
format of, 2-3 
multiple, 2-2, 2-23 
multiple objects, 2~22 
omitting source, 2-6 
precedence, 2-22 
restriction, A-9 
restrictions on, 2-27 
suppression of display, 2-27 

Action line prefixes 
see also individual prefix 
directives 

difference between, 2-26 
format of, 2-25 
ignore (-), 2-26 
silent (@), 2-27 

/ACTION qualifier, CD-4 

ADDITIONALLY_DEPENDS_ON 
in dependency rules, 3-2 

ASTLM, 3-5 

/AUDIT qualifier, 4-21, CD-5, A-2 


Backslash 
continuation character, B-2 
Building software systems, 1-6 to 1-18 


See also Software system 


Built-in macro, 3-7 
Built-in rule, 2-6, 2-8 to 2-18, 2—33, CD-14, B-2 
default macros, 2~12 
definition of, 1-5 
example of, 2-8, 2-11 
for CMS libraries, C-14 
for libraries, C—9 
for library files 
table, C-—9 
linking objects, 1-9 
modifying, 3-17 
override, 2-8 
table, C—7 
with /SCA_LIBRARY, C-10 
BYTLM, 3-5 


Cc 


Callable CMS, A-3 
Caret format 
See up-arrow character 
CDD, 4-1 
definition 
syntax of, 4-21 
history list, 4-21 
path specification, 4-21 
record, CD-5, A-3 
CDDFLAGS default macro, 4-22 
CDD/Plus 
access 
restrictions, 4-22 
definitions 
access to, 4—21 
record, A-3 
CFLAGS 
default macro, 2-17, 4-18 
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/CHANGED qualifier, CD-5 
Checkpoint file, 3-12 
/CHECK_STATUS qualifier, CD-5 
precedence, CD-5 
Child process, 2-25 
CLI symbol, 3-7, 3-8 
CLI symbol table, CD-13 
CLISYMTBL 
SYSGEN parameter, A-17 
CMS, 2-36, 3-14, 4-4 
access to single element, 4-18 
building from current generations, 4-13 
callable, A-3 
class 
specifying, 4~-13 
commands 
in description files, 4-6 
elements 
access restriction, 4-8 
automatic access of, 4-6 
explicit references to, 4-7 
including with INCLUDE, 4-18 
library specfication, 4-8 
specifying, 4-7 
-INCLUDE directive, 4-18 
libraries, 4-1 
access to, 4-4, A-3 
built-in rules for, C-14 
rules, 4-18, CD-6 
user-defined rules, 4-18 
using with MMS, 4-4 
CMSS$LIB logical name, 4-6 
CMSCOMMENT default macro, 4-18 
CMSFLAGS default macro, 4-6, 4-7, 4-13, 4-18 
redefining, 4-7 
CMS INSERT command, 4-17 
/CMS qualifier, 3-19, 4-6, 4-7, 4-19, CD-6 
/GENERATION, 4-13 
CMS SET LIBRARY, 4-6 
CMSWAIT, A-5 
Colon, 2-2 
Command procedure, 3-6 
generated with /OUTPUT, CD-12 
invoke 
from description file, 3-9 
invoking MMS, 3-6 
Comment character (!), B—1 
Comment character (#), B-1 
restriction, B—1 
Comment line, 2-3, 2-4, 2-24 
Concepts of MMS, 1-3 to 1-6 
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Continuation character 
backslash, B-2 
hyphen, 2-3, 2-4, 2-13, A-15 
hyphen(-), B-2 

Continuation character (-), B-2 


D 


DCL commands, 2-28 
DCL severity levels, CD-9 
DCL symbol, 3-9, 3-14 
DCL WAIT, 3-4 
/DEBUG qualifier 
compiling with, 2-17 
-DEFAULT directive, 2-32, 3-12 
overriding, 2-33 
Default macro, 2-12, 3-7 
CDDFLAGS, 4-22 
CMSCOMMENT, 4-18 
CMSFLAGS, 4-7, 4-13 
FMSFLAGS, 4-20 
LINK, 2~21 
LINKFLAGS, 2-21 
redefine 
example, 2-17 
redefining, 2-17 
table, C—2 
table of, C-2 
with /SCA_LIBRARY 
table, C—4 
$DELPRC system service, A-8 
Dependencies, 1-5 
definition of, 1-3 
in a single source system 
figure, 1-5 
Dependency rule, 2-2 
action lines, 2-2 
ADDITIONALLY_DEPENDS_ON, 3-2 
alternative format for, B-2 
circular dependency restriction, A~11 
comments in, 2-3 
continuing, 2-3 
example, 2-3 
double-colon in, 3-1, 3-2, A-10 
format, 2-2 
implied, 2-9, 2-20 
multiple dependencies, 3-1 
optional format, B~2 
source, 2-2 
omitting, 2-9 
tab restriction, B—1 


Dependency rule (Cont.) 
target, 2-2 
Dependency tree, 1-6 
DEPENDS _ON, 2-2 
DESCRIP.MMS, CD-3, B-1 
Description file, 2-1 to 2-42 
advanced techniques, 3-1 
built-in rules, 2-11 
CMS commands in, 4-6 
concatenated, CD-7 
creation of, 2-1 
definition of, 1-3 
dependencies in, 1-3 
elements, 2-1 
action lines, 2-1 
built-in rules, 2-1 
comment lines, 2-1 
directives, 2-1 
user-defined rules, 2-1 
example of, 2-11 
in CMS libraries, 4-19 
invoking, 2-1 
invoking command procedures, 3-9 
invoking MMS from, 3-3 
SSUFFIXES 
example, 2-34 
/DESCRIPTION qualifier, 4-19, CD-6, B-1 
Diagnostic messages 
See Error messages 
DIFFERENCES utility, 2-24 
Directives, 2-28 
see also individual directives 
DEFAULT, 2-32 
.ELSE, 2-40 
ENDIF, 2-41 
.FIRST, 2-38 
.FDEF, 2-40 
IGNORE, 2-29 
ANCLUDE, 2-37 
.LAST, 2-39 
SILENT, 2-31 
SSUFFIXES, 2-33 
table, 2-28, C-6 
Double colon 
in dependency rules, 3-2 
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.ELSE directive, 2—40 
-ENDIF directive, 2-41, A-15 
Error message, 3-5, A-1 


Error message (Cont.) 
CDD, A-2 
fatal, 2-25, A-1 
severity level, A-1 
warning, 2-25, A-1 
Error messages, A-2 to A-18 
EXIT DCL command, 2-28 


F 


Fatal error, 2-25, CD—10 
Fatal message, A-—1 


File 
access in SCA library, 4~22 
deleting, 3-17 


intermediate, CD-16 
protection, A-13 
specifications 
library modules, 3-3 
types, 2-33 
adding new, 2-34 
built-in rule, 2-8 
null, 2-37 
precedence, 2-34 
File,checkpoint 
See checkpoint file 
File,included 
See included file 
FILLM, 3-5 
quota, 2-38 
.FIRST directive, 2-38 
example of, 2-38 
FMSFLAGS default macro, 4-20 
FMS forms 
access to, 4-20 
syntax of, 4-20 
FMS libraries, 4-1, A-6 
/FORCE qualifier, CD-8 
/FROM_SOURCES qualifier, CD-8 
precedence, CD-9 


G 


/GENERATION CMS qualifier, 4-6, 4-13, A-3 
GOTO DCL command, 2-28 


H 


Help 
getting, 1-3 
HELP library, CD-9 


Index—3 


/HELP qualifier, CD-9, A-3 
Hierarchy of rule application, 2-7 


ADENTIFICATION qualifier, CD-9, A-14 
AFDEF directive, 2-40, A-15 
-IGNORE directive, 2-29, CD-10 
overriding, 2-31 
Ignore prefix (-), 2-26, 3-18, CD-10 
restriction, CD-11, B-2 
AGNORE qualifier, 2-25, 2-31, CD-9, A-1 
restriction, CD-10 
Included files, 2-34, 3-15 
building system with, 1-11 
definition of, 1-11 
in a system 
figure, 1-12 
infinite loop, A-15 
nested, 2-38 
rebuilding system with, 1-21 
source code in, 1-11 
.INCLUDE directive, 2~37, 4-18, CD-6, B-3 
INQUIRE command, 3-10 
Invoking MMS, 1-2 
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.LAST directive, 2-39, 3-17, CD-15 
example, 2-40 
multiple targets, 2-39 
Library 
as sources, 4-4 
built-in rules for, C—9 
CMS, 44 
access to elements in, 4-6, 4-7 
FMS, 4-20 
syntax of forms in, 4-20 
object 
building system with, 1-16 
VMS, 4-1 
syntax of modules in, 4-2 
Library module, 4-2 
as targets, 3-3 
double colon dependencies, 3-3, 4-2 
file specifications, 3-3, 4-2 
restriction, 4-2 
logical names, 4-2 
multiple, 4-2 
non-VMS file specifications, 4-3 
specification, A-16 
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Line, action 
See action line 
LINK DCL command, 2-40 
LINKFLAGS 
redefined, 3-8 
/LIST qualifier, CD-10 
Logical names, 3—25 
CMS library specifications, 4-17 
library modules, 4-2 
restriction, 4-2 
SCA$LIBRARY, 4-23 
LOGOUT DCL command, 2-28 
/LOG qualifier, CD-11 


Macro, 2—12 
built-in, 3-7 
CLI symbol, 2-14, 3-19 
default, 2-12, 3-7 
LINK, 2-21 
LINKFLAGS, 2-21 
table of, C—2 
defining, 2-14, 2-15, 2-20 
defining in a file, 2-16 
defining on command line, 2-16 
defining on the command line, 3-18, CD—11 
definition file, 2-16 
example of, 2-15 
expanding, 2-15, 3-18 
format of, 2-13 
invoking, 2-14, 2-15 
$MMS, 3-4 
$(MMSQUALIFIERS), 3-5 
$(MMSTARGETS), 3-5 
processing 
order of, 2-14 
punctuation, 2-14 
recursive, 2-15 
redefining, 2-16, 2-17 
special, 2-18, 3-7 
abbreviations, B-3 
definition, 2-18 
expansion of, 2-20 
MMS$TARGET, C-—4 
MMS$TARGET_NAME, C—4 
replacing, 2-18 
symbols, 2-18 
table of, C-4 
used with libraries, 4~3 
user-defined, 2-20, 3-7 


/MACRO qualifier, 2-14, 2-16, 3-16, 4-13, CD-11, 
A-~16 

MAKEFILE., CD-3, B-1 
make utility 

differences with MMS, B-1 
Messages 

error, A-2 
Messages, MMS, A-1 
MMS 

concepts, 1-3 to 1-6 

help, 1-3 

invoking, 1-2 

overview, 1-1 to 1-2 
$MMS 

special macro, 2-28 
MMS$CHANGED_LIST 

example of, 2-19 
MMS$LIB_ELEMENT, 4-4 
MMS$RULES 

logical name, CD-14 
MMS$SOURCE, 2-9, 2-13, 2-18, 2-21, 2-35 

example of, 2-18 

used with libraries, 4—3 
MMS$SOURCE_LIST, 2-13, 2-21, 2-35 
MMS$STATUS, 2-25, CD-5, CD-11, CD-14, A-17 
MMS$TARGET, 2-32, C-4 

example of, 2-19 

used with libraries, 4-3 
MMS$TARGET_NAME, 2-13 

special macro, C-—4 

used with libraries, 4-4 
$(MMS) reserved macro, 3-4, CD-5 
MMS command, CD-3 

abbreviating, CD-4 

qualifiers, CD-4 


see also Qualifiers 
$(MMSQUALIFIERS) reserved macro, 3-5, CD-15 
MMS quotas, 3-5 
$(MMSTARGETS) reserved macro, 3-5 
Mnemonic names, 2-2, 2-5 
Multiple outputs, 3-26 
Multiple programming language system 
building, 1-9 
figure, 1-10 
rebuilding, 1-21 
Multiple source system 
building, 1-8 
figure, 1-9 
rebuilding, 1-21 
Multiple targets 
building system with, 1-13 


Multiple targets (Cont.) 
rebuilding system with, 1-22 
system with more than one executable image 
figure, 1-15 
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/NOACTION qualifier, 2-31, 3-4, 4-22, CD-4 
/NOCHECK_STATUS qualifier, CD-5 
/NOCMS qualifier, 4-7, 4-18, CD-6 
/NODESCRIPTION qualifier, CD-4, CD-6, CD-8 
/NOIGNORE qualifier, CD-9 

/NOLIST qualifier, 2-17, 2-19, CD-10 
/NOLOG qualifier, CD-11 

/NOOVERRIDE qualifier, CD-12 
/NOREVISE_DATE qualifier, CD-13 
/NORULES qualifier, CD-6, CD-14 
/NOSCA_LIBRARY qualifier, CD~15 
/NOSKIP_INTERMEDIATE qualifier, CD-16 
/NOVERIFY qualifier, CD~17 

Null string, 4-22 


O 


Object files, 3-3 
Object libraries, 3-20 

maintaining, 3-2 
Object library 

building system with, 1-16 

definition of, 1-16 

in a system 

figure, 1-17 

rebuilding system with, 1-22 
Object module 

definition of, 1-16 
/OBJECT qualifier, 2-17, 2-19 
/OUTPUT qualifier, 2-24, 2-26, 2-31, CD-4, CD-12 
/OVERRIDE qualifier, 2-14, 3-7, 4-14, CD-12 
Overview of MMS, 1-1 to 1-2 


p 


Page file quota, 3-5 
Parallel processing, 3-19 
Parent process, 2-25, 3-3 
PASCAL, 2-9, 2-13 
environment files, 3-29 
.PEN files, 3-29 
PFLAGS, 2-9, 2-13 
redefined, 3-8 
PGFLQUO, 3-5 
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PRCLM, 3-4, 3-5 
Precedence list, 2-33 

table of, C-6 
-PRECIOUS restriction, B-1 
Process quotas 


See quotas 


Q 


Qualifiers 
abbreviating, CD-4 
/ACTION, CD-4 
/AUDIT, 4-21 
/CHANGED, CD-5 
/CHECK_STATUS, CD-5 
/ICMS, 4-6, 4-19, CD-6 
/DESCRIPTION, CD-6 
/FORCE, CD-8 
/FROM_SOURCES, CD-8 
/HELP, CD-9 
ADENTIFICATION, CD-—9 
/IGNORE, CD-9 
/LIST, CD-10 
/LOG, CD-i1 
/MACRO, CD-11 
/OUTPUT, CD-12 
/OVERRIDE, CD-12 
/REVISE_DATE, CD—13 
/RULES, CD-14 
/SCA_LIBRARY, CD-15 
/SKIP_INTERMEDIATE, CD-16 
INERIFY, CD-17 
Quotas, A-7 
page file, 3-5 
process, 3-5, A-6 
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Rebuilding software systems, 1-18 to 1-22 
See also Software system 
Reserved macros 
$(MMS), 3-5 
$(MMSQUALIFIERS), 3-5 
$(MMSTARGETS), 3-5 
Restrictions to CDD/Plus access, 4-22 
/REVISE_DATE qualifier, CD-13, A-13 
CMS libraries, 4-6 
FMS forms, 4-21 
precedence, CD-14 
restriction, CD-14 
Revision time, 2-6, CD-8, A-2 
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RSX libraries, 4-1 
Rule 
built-in 
see built-in rules 
dependency 
see dependency rule 
file, 4-18 
hierarchy of application, 2-7 
user-defined 
see user-defined rules 
/RULES qualifier, CD-14 
precedence, CD-14 


S 


SCA 
data file, 4-23 
library, 4-1, 4-22 
$(SCA) macro, CD-15 
SCA database, CD-15 
$(SCA_LIBRARY) macro, CD-15 
/SCA_LIBRARY qualifier, 4-22, CD-15 
built-in rule changes, C—-10 
macro changes, C—4 
SET NOVERIFYDCL command, 2-28 
SET ON DCL command, 2-28 
SET VERIFY DCL command, 2-28 
$SEVERITY, 2-25 
Severity errors, 2-25, A-11 
SILENT directive, 2-31, 3-15, CD-17 
example, 2-31 
overriding, 2-31 
used with a colon, B-3 
Silent prefix (@), 2-26, 2-27, CD-5, CD-17 
restriction, B-2 
Single source system 
building, 1-7 
dependencies in 
figure, 1-5: 
rebuilding, 1-20 
/SKIP_INTERMEDIATE qualifier, 3-18, 3-19, CD-16 
Software system 
building, 1-6 to 1-18 
multiple programming language system, 1-9 
figure, 1-10 
multiple source system, 1-8 
figure, 1-9 
single source system, 1-7 
with an object library, 1-16 
figure, 1-17 
with a specific target, 1-15 


Software system 
building (Cont.) 
with included files, 1-11 
figure, 1-12 
with multiple targets, 1-13 
missing component, 1—20 
rebuilding, 1-18 
figure, 1-19 
multiple programming language system, 1-21 
multiple source system, 1-21 
single source system, 1-20 
with an object library, 1-22 
with included files, 1-21 
with multiple targets, 1-22 
with more than one executable image 
figure, 1-15 
Source, 2-3 
a non-file, 2-6 
definition of, 1-4 
libraries, 4-4 
missing, 3-12 
mnemonic names for, 2-5 
multiple, 2-6 
Source code 
file, 2-6 
included files with, 1-11 
SPAWN DCL command, 2-28 
Special macros, 2-12 
See Macro, special 
expansion of, 2-20 
See Macro, special, 2-18 
Specific target 
building, 1-15 
Statistics, 3-12 
$STATUS, 2-25, 4-20 
STOP DCL command, 2-28, A-8 
Subprocesses, 4-20, A-8, B-1 
CMS as a, 4-6 
invoking MMS as, 3-3 
process quotas, 3-4 
spawned, 3-3 
-SUFFIXES directive, 2-33, A-13 
adding new file type, 2-34 
format of, 2-33 
Suffixes precedence list, 2-10, 2-33, CD-14 
figure, 2-10 
null file type, 2-37 
table of, C-6 
Symbol scope, A-17 
SYSSERROR, CD-12, A-6 
SYSSINPUT, 2-28 


SYS$OUTPUT, 2-24, 2-31, 2-32, CD-4 
SYSGEN parameter 
CLISYMTBL, A-17 
System building 
changing options, 3-10 
from CMS class, 4-13 
problem solving, 1-5 
recreating previous versions, 4-13 
user-defined rules, 2-21 


T 


Target, 2-2, 2-23 
a non-file, 2-6 
building specific, 1-15 
default, CD-7 
definition of, 1-4 
mnemonic names for, 2-5 
multiple, 2-6 
building system with, 1-13 
rebuilding system with, 1-22 
on command line, 2-4, 2-6 
TARGET-NAME.MMS, CD-3 
Tilde 
CMS elements, 4-4 
format, 4-4, 4-6, 4-7, 4-18, 4-19, CD-6, A-5 
Time, revision 
See revision time 
Time stamps, 3-13 


U 


Up-arrow character (*), 4-21 
User-defined macros, 2-12, 3-7, 3-16 
User-defined rules, 2—20 

accessing CMS element, 4-18 

alternative format for, B-2 

built-in rule 

precedence, 2-20 

creating, 2-20 

example of, 2-20 

format, 2-20 
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VAX DEC/Module Management System, See MMS 
/VERIFY qualifier, 2-31, CD-17 
Virtual memory, 3-5 
VMS library access, 4—1 
VMS wildcard characters 
See wildcards 
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Warning errors, CD-10 
Warning message, A-—1 
Wildcards, A-10 

%, B-2 

?, B~2 

VMS, 4-3 
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How to Order Additional Documentation 





Technical Support 


If you need help deciding which documentation best meets your needs, call 800-343-4040 
before placing your electronic, telephone, or direct mail order. 


Electronic Orders 


To place an order at the Electronic Store, dial 800-DEC-DEMO (800-332-3366) using 
a 1200- or 2400-baud modem. If you need assistance using the Electronic Store, 
call 800-DIGITAL (800-344-4825). 


Telephone and Direct Mail Orders 


Your Location Call Contact 
Continental USA, 800-DIGITAL Digital Equipment Corporation 
Alaska, or Hawaii P.O. Box CS2008 

Nashua, New Hampshire 03061 
Puerto Rico 809-754-7575 Local Digital subsidiary 
Canada 800-267-6215 Digital Equipment of Canada 


Attn: DECdirect Operations KAO2/2 
P.O. Box 13000 

100 Herzberg Road 

Kanata, Ontario, Canada K2K 2A6 


International —————_ Local Digital subsidiary or 
approved distributor 

Internal! ——_—___— USASSB Order Processing - WMO/E15 
or 


U.S. Area Software Supply Business 
Digital Equipment Corporation 
Westminster, Massachusetts 01473 


1For internal orders, you must submit an Internal Software Order Form (EN-01740-07). 
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